Earlier  
Posted Nick Remark
#openstack-nova - 2024-03-19
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 opendevmeet The meeting name has been set to 'nova'
16:00:45 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
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 bauzas #startmeeting 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
16:18:01 sean-k-mooney becuase there was an actual issue
16:19:51 sean-k-mooney anyway lets move on we can chat about this after the meeting

Earlier   Later