Earlier  
Posted Nick Remark
#openstack-nova - 2024-03-19
13:21:03 opendevreview Merged openstack/nova stable/2023.2: Power on cores for isolated emulator threads https://review.opendev.org/c/openstack/nova/+/913195
13:40:59 bauzas fwiesel: cool
13:44:52 fwiesel But I do not know enough how it is supposed to work in libvirt to make a good suggestion on how to implement it differently. I mean, I assume it makes sense that it is implemented the way it is.
13:53:08 bauzas fwiesel: you're referring to https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4132-L4137
14:00:25 bauzas fwiesel: _rebuild_default_impl is a virt-agnostic solution for rebuild which does delete the old guest and then create a new one https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3648-L3731
14:02:52 gibi elodilles: thanks for the reviews so far. the parent of https://review.opendev.org/c/openstack/nova/+/913196 is merged now. So when you have time please check this backport too
14:02:56 bauzas as you can read, we power off the guest, detach its volumes, (reimage the root disk if volume-backed), destroy the guest, attach the volumes again and spawn the guest
14:14:52 sean-k-mooney fwiesel: the way its currently implemtned shoudl wor for vmware too
14:15:22 sean-k-mooney fwiesel: the only driver that does anythign custom is ironic
14:16:09 sean-k-mooney the vmware dirver can provide its own solution
14:17:43 elodilles gibi: ACK, will do
14:18:44 sean-k-mooney the imporant thing to remember about rebuild is rebuild is not a move operations, evacuate is a rebuild to a diffent host but by default a normal rebuild shoudl never change host. if you change image however you do need to call the schduler with the current host adn the existin flavor and new iamge to confirm that host is valid. that should all be handeled for you in the
14:18:46 sean-k-mooney generic compute manager code so the only thing the driver level rebuidl needs to do is ensure the root disk is reimaged
14:19:35 sean-k-mooney if there is a more effiecnt way to do that in vmware then the generic approch then that is fine to use
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

Earlier   Later