| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-10-21 | |||
| 07:05:42 | songwenping_ | gibi, sean-k-mooney:please review cyborg microversion support in https://review.opendev.org/#/c/738428/ | |
| 07:12:49 | gibi | brinzhang, songwenping_: ack, I will try to get to these patches but this week and next week seems pretty full of other things | |
| 07:12:52 | gibi | so no promises | |
| 07:13:17 | songwenping_ | gibi: no hurry, thanks. | |
| 07:14:45 | brinzhang | gibi: ack, thanks | |
| 07:35:54 | bauzas | gibi: seen it ? ^ | |
| 07:37:35 | gibi | bauzas: saw it, on a morning meeting, but after that I will jump on it | |
| 07:43:01 | bauzas | gibi: tl;dr we need to review merged code vs. gerrit approvals | |
| 07:43:14 | bauzas | from Oct 1. | |
| 07:55:23 | lyarwood | FWIW all of my master changes look valid and untouched in there | |
| 08:00:16 | gibi | I'm done with nova-specs and nova master will check novaclient next | |
| 08:00:31 | gibi | lyarwood: could you check the nova stable branches? | |
| 08:01:05 | gibi | python-novaclient is clean too | |
| 08:01:52 | lyarwood | gibi: ack looking now | |
| 08:01:57 | gibi | thanks | |
| 08:02:04 | gibi | I go and check placement | |
| 08:02:46 | gibi | placment and osc_placement clean too | |
| 08:06:02 | lyarwood | gibi: stable LGTM, elod can you also check? https://static.opendev.org/project/opendev.org/gerrit-diffs/openstack/nova.git/stable/ | |
| 08:14:00 | openstack | bug 1899835 in OpenStack Compute (nova) "n-cpu attempts to disconnect volumes after early pre_live_migration failures on the destination during a live migration" [Undecided,New] https://launchpad.net/bugs/1899835 - Assigned to Lee Yarwood (lyarwood) | |
| 08:14:00 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Add regression test for bug #1899835 https://review.opendev.org/758239 | |
| 08:15:09 | gibi | lyarwood: elod is on PTO today I can go through stable during the day | |
| 08:15:42 | gibi | actually I can do it right now | |
| 08:22:23 | gibi | lyarwood: nova stable looks clean to me too | |
| 08:23:35 | lyarwood | ack thanks | |
| 08:23:53 | gibi | I will check os-vif | |
| 08:23:57 | gibi | then we are done | |
| 08:25:26 | gibi | os-vif seems clean to | |
| 08:25:28 | gibi | too | |
| 08:28:56 | bauzas | ++ for checking | |
| 08:38:32 | gibi | the nova RC1 and 22.0.0 release looks good in release repo too | |
| 09:00:53 | bauzas | (which should have been yesterday) | |
| 09:06:36 | openstack | bug 1894804 in qemu (Ubuntu) "Second DEVICE_DELETED event missing during virtio-blk disk device detach" [Undecided,Incomplete] https://launchpad.net/bugs/1894804 | |
| 09:06:36 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Revert "releasenote: Add known issue for bug #1894804" https://review.opendev.org/758971 | |
| 10:02:04 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Add instance_state to ensure volume attachment successful https://review.opendev.org/758920 | |
| 10:39:43 | openstackgerrit | Jorhson Deng proposed openstack/nova-specs master: Add instance_state to ensure volume attachment successful https://review.opendev.org/758920 | |
| 12:16:28 | sean-k-mooney | by the way i have looked at os-vif and it looks fine i was going to start on nova https://etherpad.opendev.org/p/nova-patches-since-oct-1st | |
| 12:16:54 | sean-k-mooney | have people already dont that if not im going to make my way form top to bottom that currently for master | |
| 12:17:05 | sean-k-mooney | using the oslo script | |
| 12:23:51 | gibi | stephenfin: you missed one thing in https://review.opendev.org/#/c/749317/3/nova/compute/api.py@6214 | |
| 12:24:11 | stephenfin | gibi: whoops; I'll do a follow-up | |
| 12:24:19 | gibi | sean-k-mooney: lyarwood and I looked at nova | |
| 12:24:34 | sean-k-mooney | ok so i assume we are good then | |
| 12:24:49 | sean-k-mooney | ill skip it if ye have already | |
| 12:24:50 | gibi | sean-k-mooney: http://lists.openstack.org/pipermail/openstack-discuss/2020-October/018154.html | |
| 12:25:09 | gibi | stephenfin: ack, +2 then | |
| 12:25:20 | sean-k-mooney | cool | |
| 12:30:52 | sean-k-mooney | is devstack in #openstack-qa | |
| 12:31:30 | lyarwood | yes | |
| 12:47:34 | gibi | stephenfin: are we using the same strategy to remove os-agents that we did for nova-network related APIs? https://review.opendev.org/#/c/749309/3/releasenotes/notes/remove-xenapi-driver-194756049f22dc9e.yaml@9 | |
| 12:48:06 | stephenfin | gibi: yes, that seems the most sensible approach to me | |
| 12:48:24 | stephenfin | they're dead APIs without virt driver support | |
| 12:54:00 | gibi | stephenfin: thanks I wanted to make sure that we are OK to have a breaking API change without a microverison. But here I agree that having a microvesion does not help much | |
| 12:54:37 | stephenfin | yeah, a microversion doesn't make sense here since requesting the older version won't magically restore the older behavior | |
| 12:55:05 | gibi | for xenapi yes, for non xenapi it could restore the empty result instead of 410 | |
| 12:56:12 | gibi | but I hope non xenapi user did not use this API :) | |
| 12:56:38 | stephenfin | True :) | |
| 13:01:09 | gibi | thanks, approved | |
| 13:06:09 | openstack | Launchpad bug 1900800 in OpenStack Compute (nova) "VGPUs is not recreated on host reboot" [Low,Confirmed] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 13:06:09 | bauzas | I feel stupid today... https://bugs.launchpad.net/nova/+bug/1900800 | |
| 13:06:28 | bauzas | the thing I wrote : if mdev_not_exists(): lookup_the_mdev() | |
| 13:06:34 | bauzas | bravo sylvain... | |
| 13:08:30 | gibi | bauzas: don't be hard on yourself. everybody make mistakes. you can look at the good side, somebody is using the feature your implemented! | |
| 13:08:58 | bauzas | well, this one was terrible tho | |
| 13:09:15 | bauzas | even my wife who's accountant can understand the bug | |
| 13:09:37 | bauzas | and no clear solutions except "well, don't reboot" are viable | |
| 13:12:15 | gibi | bauzas: Eigi has some suggestion in the bug about reassigning every gpu at host reboot | |
| 13:13:50 | bauzas | gibi: well, I'd prefer pursuing the idea that Nova shouldn't honestly try to support reboots | |
| 13:14:02 | bauzas | oVirt doesn't do it, neither KVM | |
| 13:14:31 | bauzas | we provided this as a gentle way but changing this would require substantial changes that are due to something external to nova | |
| 13:15:09 | bauzas | but I'll speak about a workaround, which is to use a 3rd-party tool https://github.com/mdevctl/mdevctl | |
| 13:15:12 | gibi | bauzas: do you mean nova should not persist end user VMs, or just not to try to recover them automatically at host reboot? | |
| 13:15:18 | bauzas | gibi: the latter | |
| 13:15:57 | gibi | bauzas: but then after a host reboot a VM hard-reboot from the API should work, isn't it? | |
| 13:16:09 | gibi | or expected to work | |
| 13:16:35 | bauzas | gibi: it would be the responsability of the operator to recreate the former mdevs that diseappeared at reboot before restarting n-cpu | |
| 13:16:51 | gibi | so no automatic recovery of the compute host at all | |
| 13:17:01 | gibi | interesting | |
| 13:17:43 | bauzas | gibi: well, correct me if I'm wrong but SR-IOV VFs aren't either created or persisted by neutron ? | |
| 13:17:48 | bauzas | or nova | |
| 13:18:05 | bauzas | we just lookup the resources that were allocated before, right? | |
| 13:18:31 | gibi | bauzas: yes, we expect that the admi of the comute host made sure that the VFs are re-created during host reboot | |
| 13:18:49 | bauzas | gibi: so, I guess we should make the same expectation for the mdevs | |
| 13:18:55 | gibi | agree | |
| 13:19:06 | bauzas | and there is a tool | |
| 13:19:40 | bauzas | that doesn't solve my customers, but that goes a Red Hat thing, not an upstream problme | |
| 13:21:17 | gibi | bauzas: so with mdevs you went a different way that how nova manages PCI devices. Nova never tries to create SRIOV VFs | |
| 13:21:38 | bauzas | indeed | |
| 13:22:00 | bauzas | when I started on it, I was somehow having the expectation that mdevs were persistent | |
| 13:22:03 | gibi | still VFs might dissapeare during host reboot and I guess that means VMs depending on such VF goes to error | |
| 13:22:45 | bauzas | so I provided a convenient workaround for recreating the mdev, but now we're smarter, this hack can't longer work | |
| 13:23:18 | bauzas | and one day if we go with allocating mdevs based on NUMA affinity, then we would absolutely need to reallocate the same mdev from the same pGPU | |
| 13:23:23 | bauzas | at reboot | |
| 13:23:31 | bauzas | because performance matters | |
| 13:24:12 | bauzas | also, you could have two different mdev types for each GPU | |
| 13:24:25 | bauzas | one for performance and one for inference, per say | |
| 13:24:41 | bauzas | we couldn't just pick any mdev at the best guess | |
| 13:25:00 | gibi | yeah, true | |
| 13:25:04 | bauzas | anyway, I think I'll reply | |
| 13:25:15 | bauzas | specs reviews I promised | |
| 13:38:36 | dansmith | johnthetubaguy: does that api make sense to anything other than nova/ironic? | |