| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-03-19 | |||
| 14:20:05 | dansmith | not "should never change host" but "does not change host" | |
| 14:20:14 | dansmith | even the driver shouldn't be able to override that | |
| 14:22:08 | sean-k-mooney | right | |
| 14:22:31 | sean-k-mooney | im just tyring to say that if there was to be a vmware version fo rebuidl in the vmware driver the only thing it should od is reimage the disk | |
| 14:22:47 | sean-k-mooney | the vm must remain on the same hypervior host | |
| 14:23:14 | sean-k-mooney | i just mentioned evcautate because the driver code will have to work when called in that code path too | |
| 14:23:26 | dansmith | yep | |
| 14:27:56 | fwiesel | sean-k-mooney: The current implementation calls driver.destroy, and *then* calls detach volume. In my mind, that shouldn't work in the general case. | |
| 14:33:03 | bauzas | no | |
| 14:33:13 | bauzas | fwiesel: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3675-L3676 | |
| 14:33:44 | bauzas | poweroff, detach, destroy is the workflow | |
| 14:34:38 | fwiesel | Destroy: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3695-L3701 and then via https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3713-L3715 comes https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3589-L3595 | |
| 14:35:43 | fwiesel | bauzas: The root volume is being detached after the instance has been destroyed if reimage_boot_volume and is_volume_backed | |
| 14:36:26 | fwiesel | So, poweroff, detach everything except the root-disk, destroy, detach the root_disk (in the case of reimage_boot_volume and is_volume_backed) | |
| 14:36:31 | bauzas | we still detach the volumes, including the root bdm in https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3675-L3676 | |
| 14:37:49 | fwiesel | Sure, and after the desotry the _rebuild_volume_backed_instance -> _detach_root_volume | |
| 14:40:39 | fwiesel | Well, we have `reimage_boot_volume=True` ergo `detach_root_bdm = not reimage_boot_volume = False`, so `detach_block_devices(..., detach_root_bdm=False)`. | |
| 14:51:09 | bauzas | fwiesel: ah you're right, it's a bool | |
| 14:51:25 | bauzas | okay, so the root volume isn't detached yet, my bad | |
| 14:53:24 | bauzas | and ack, we rebuild the root volume in _rebuild_volume_backed_instance() | |
| 14:55:26 | bauzas | where we detach the volume, delete the old attachment, and then reimage the volume thru cinder | |
| 14:56:13 | bauzas | interestingly enough, we destroy the guest indeed before the detach, but we skip its bdm when we call the driver destroy | |
| 15:06:15 | fwiesel | There is probably a reason for that. I mean it is done very explicitly so. But as I said, I don't have any idea why. | |
| 15:21:16 | opendevreview | Fabian Wiesel proposed openstack/nova master: Do not close returned image-chunk iterator & get_verifier early https://review.opendev.org/c/openstack/nova/+/909474 | |
| 15:30:14 | opendevreview | Elod Illes proposed openstack/nova stable/2024.1: [stable-only] Update .gitreview for stable/2024.1 https://review.opendev.org/c/openstack/nova/+/913631 | |
| 15:30:40 | opendevreview | Elod Illes proposed openstack/nova stable/2024.1: [stable-only] Update TOX_CONSTRAINTS_FILE for stable/2024.1 https://review.opendev.org/c/openstack/nova/+/913632 | |
| 15:30:52 | opendevreview | Elod Illes proposed openstack/nova stable/2024.1: [stable-only] Update TOX_CONSTRAINTS_FILE for stable/2024.1 https://review.opendev.org/c/openstack/nova/+/913632 | |
| 16:00:45 | bauzas | #startmeeting nova | |
| 16:00:45 | opendevmeet | Meeting started Tue Mar 19 16:00:45 2024 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:00:45 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:45 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:48 | bauzas | heyho | |
| 16:00:52 | bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 16:01:26 | fwiesel | o/ | |
| 16:01:30 | elodilles | o/ | |
| 16:01:41 | auniyal | o/ | |
| 16:01:56 | gibi | o/j | |
| 16:02:25 | bauzas | okay, let's sofly start | |
| 16:02:31 | sean-k-mooney | o/ | |
| 16:02:36 | grandchild | o/ | |
| 16:03:32 | bauzas | #topic Bugs (stuck/critical) | |
| 16:03:50 | bauzas | #info No Critical bug | |
| 16:03:56 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 63 new untriaged bugs (-2 since the last meeting) | |
| 16:04:01 | bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | |
| 16:04:15 | bauzas | gibi: could you please take the baton for this week ? | |
| 16:04:56 | gibi | bauzas: sorry I cannot promise to do meaningful triage this week either | |
| 16:05:03 | gibi | can we skip me?j | |
| 16:05:27 | bauzas | okay | |
| 16:05:34 | gibi | I hope I will have more time in the coming months | |
| 16:05:51 | bauzas | melwitt is the next in the queue | |
| 16:05:57 | bauzas | melwitt: would you be okay ? | |
| 16:07:14 | bauzas | okay, anyone else wanting to take the baton ? if not, I'll take it again... :) | |
| 16:08:13 | bauzas | okay | |
| 16:08:20 | elodilles | i'd rather wait until we release 2024.1 Caracal o:) | |
| 16:08:28 | bauzas | #info bug baton is bauzas | |
| 16:08:50 | bauzas | moving on | |
| 16:08:55 | bauzas | #topic Gate status | |
| 16:08:59 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | |
| 16:09:03 | bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | |
| 16:09:07 | bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | |
| 16:09:13 | bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:09:24 | bauzas | anything to discuss about the gate ? | |
| 16:09:27 | bauzas | oh, one point | |
| 16:09:48 | bauzas | I just saw slaweq's email on bare rechecks | |
| 16:10:01 | Uggla | o/ | |
| 16:10:22 | bauzas | as a reminder, please avoid to say only "recheck" when you have a gate failure | |
| 16:10:38 | dansmith | or "recheck unrelated" | |
| 16:10:45 | bauzas | and please add a good comment explaining what's the root problem | |
| 16:10:47 | dansmith | it can be unrelated, but at least say why | |
| 16:10:52 | bauzas | and try to find a second to understand the reason | |
| 16:11:17 | bauzas | yeah, or at least please tell in the comment which job fails and with which exception | |
| 16:11:59 | bauzas | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/7L6DSFN6GB65FBVHQATTLSQ7HWGBZJHM/ | |
| 16:12:13 | sean-k-mooney | honestly i dont think calling this out here helps | |
| 16:12:14 | bauzas | #info please avoid bare rechecks | |
| 16:12:34 | dansmith | sean-k-mooney: really? the tc has asked PTLs and other project leaders to help get this word out | |
| 16:12:37 | sean-k-mooney | the people that are here already know we should avoid it | |
| 16:13:06 | bauzas | not only folks discussing here look at our meetings :) | |
| 16:13:08 | sean-k-mooney | dansmith: sure but doing this in the team metting i dont think helps | |
| 16:13:25 | dansmith | sean-k-mooney: it's exactly what we've asked for, AFAIK | |
| 16:13:28 | sean-k-mooney | ok but we disucssed about stoping to do this here in the past | |
| 16:13:29 | bauzas | I know some folks look at our minutes | |
| 16:13:37 | dansmith | and I think it does help because as bauzas says, people might not be here but read the minutes | |
| 16:13:59 | sean-k-mooney | ok but we stopped doing it in meeting becasue we didnt think it was working | |
| 16:14:12 | dansmith | sean-k-mooney: 15% on nova are still bare, and a higher proportion are "recheck unrelated" so there's still work to do | |
| 16:14:13 | sean-k-mooney | we can go back to doing it | |
| 16:14:24 | bauzas | 16% is a bad value IMHO | |
| 16:14:38 | dansmith | bauzas: better than some projects for sure, but still work to do yeah | |
| 16:14:42 | bauzas | so I'll then discuss this every meeting | |
| 16:15:04 | sean-k-mooney | do we have the list of those because i dont think just callign it out here is going to have an impact | |
| 16:15:26 | bauzas | #action bauzas to tell about the bare rechecks every week in our meeting | |
| 16:15:43 | bauzas | sean-k-mooney: please look at the link above | |
| 16:15:50 | sean-k-mooney | i have the email open | |
| 16:16:25 | bauzas | we had 16 bare rechecks against 105 rechecks, so we have 15% | |
| 16:16:46 | sean-k-mooney | i might see if i can pull out the bare rehceck and see what there were | |
| 16:16:49 | bauzas | fwiw, I can find which changes have bare rechecks | |
| 16:16:57 | bauzas | this is quite simple | |
| 16:17:20 | bauzas | but I don't want to ping folks saying "dude, don't do it" | |
| 16:17:30 | sean-k-mooney | there are a few poepl that tend to only review +1 | |
| 16:17:41 | sean-k-mooney | and i wonder if its the same subset that are blind rechecking | |
| 16:17:51 | sean-k-mooney | i did ask one person to stopp rechecking | |