| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-08-05 | |||
| 16:29:05 | sean-k-mooney | and possibel backporting that based on dicusssion with teh stable team | |
| 16:29:20 | melwitt | I agree with dansmith | |
| 16:29:41 | sean-k-mooney | dansmith: well the default never changed in libvirt. it still deleted on undefine by defualt. they just added the ablity to keep it in later release | |
| 16:29:56 | sean-k-mooney | so do we agree to treat this a logic bug in nova | |
| 16:30:03 | sean-k-mooney | i.e. that we didnt account for how this actully works | |
| 16:30:24 | sean-k-mooney | and if so are we ok with usign the flags to adress that | |
| 16:30:58 | sean-k-mooney | jssfr: yes the stable plociy does not allow feature backports upstream | |
| 16:31:05 | jssfr | aha, thanks! | |
| 16:31:11 | sean-k-mooney | jssfr: there are very limited excptions to that | |
| 16:31:52 | jssfr | noted, thanks. | |
| 16:32:25 | melwitt | I support backporting use of the flags (with libvirt version conditional) | |
| 16:32:40 | sean-k-mooney | im +1 on treating it as a but and fixing it by approatbly passing the flags to undefine based on if we are deleting the instance or just undefining for some other reason | |
| 16:33:31 | NicolaiRuckel | this applies to both vTPM and UEFI, right? | |
| 16:33:33 | sean-k-mooney | s/as a but/as a bug/ | |
| 16:33:49 | sean-k-mooney | so its the same patther and the same logic bug | |
| 16:34:07 | sean-k-mooney | so i think we could apply the same direction to both | |
| 16:34:34 | melwitt | +1 | |
| 16:34:39 | sean-k-mooney | the specific libvirt verions may differ for the relevent flags | |
| 16:34:39 | jssfr | sean-k-mooney, does this only apply for the accidental deletion on undefine for UEFI, or also for the loss of NVRAM data during migrations? | |
| 16:34:46 | sean-k-mooney | so we shoudl fix both as seperate patches | |
| 16:35:17 | sean-k-mooney | jssfr: nvram data is actully copied during live migration i belive | |
| 16:35:38 | sean-k-mooney | cold migration is sperate. we shoudl focus on the non move operations cases first | |
| 16:36:00 | jssfr | NicolaiRuckel, any evidence of nvram preservation during live migrations when initially rebased https://review.opendev.org/c/openstack/nova/+/621646 ? | |
| 16:36:15 | sean-k-mooney | im not sure which subset of opertions loose nvram data but fixing all fo them is not going to be a singel bug | |
| 16:36:27 | jssfr | understood, thanks. | |
| 16:36:31 | sean-k-mooney | jssfr: i belive its copied by qemu | |
| 16:36:51 | jssfr | aha | |
| 16:37:13 | jssfr | NicolaiRuckel, we'll have to double-check that in the devstack, without the rebased patches. | |
| 16:37:23 | NicolaiRuckel | yeah, I didn't try it yet | |
| 16:37:41 | NicolaiRuckel | There were so many failing test cases that I wanted to clean that up first. | |
| 16:38:02 | sean-k-mooney | i would sugget fixign one bug first then the other | |
| 16:38:18 | sean-k-mooney | i dont really have a prefence in order but proably vtpm might be less work | |
| 16:38:49 | sean-k-mooney | for nvram there is existing tech debt that need to be unwornd related to rebuild | |
| 16:38:53 | jssfr | sean-k-mooney, okay, I'll get to work on making the vTPM patch ready for merge this week then. | |
| 16:39:22 | jssfr | probably not going to *finish* it this week though. What is the time we need to submit the polished patch (incl. tests) for it to be realistically merged for Flamingo? | |
| 16:39:48 | sean-k-mooney | you have about 3 weeks | |
| 16:39:54 | jssfr | okay, so 1w before FF | |
| 16:39:55 | jssfr | noted | |
| 16:40:03 | sean-k-mooney | well you have until FF | |
| 16:40:14 | jssfr | oh I thought that was in 4 weeks. | |
| 16:40:26 | Uggla | A bit less than 4 weeks | |
| 16:40:37 | jssfr | right | |
| 16:40:38 | sean-k-mooney | after which it woudl need a backport but its not a regressin intoduced in this cycle so between FF and RC1 we dont fix a lot of latent bugs | |
| 16:40:54 | sean-k-mooney | after rc 1 is cut the branch woudl be reopen for bugfixes again | |
| 16:41:00 | Uggla | FF will be August 28th | |
| 16:41:15 | jssfr | it should be doable to finish it in two weeks, so I'll aim for a submission before or on 2025-08-19 | |
| 16:41:18 | sean-k-mooney | yep that why i said about 3 weeks | |
| 16:41:38 | NicolaiRuckel | I'll continue with rebasing/fixing the UEFI patch in the meantime. | |
| 16:44:45 | sean-k-mooney | i think we can move on if there are other topic unless there are any final objections? | |
| 16:45:24 | jssfr | I'd probably jump out of the meeting then. I'll stay reachable here as usual though if there's any later remarks. Thanks for all the input! | |
| 16:46:15 | Uggla | ok I guess melwitt point was covered ^ | |
| 16:46:33 | Uggla | anything else to discuss ? | |
| 16:47:40 | jssfr | okay, text you all later, thanks! | |
| 16:52:59 | Uggla | As we are almost on the top of the hour, I'll skip bug scrubbing. | |
| 16:53:44 | Uggla | Thanks all, see you next week. | |
| 16:53:50 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-05-16.01.log.html | |
| 16:53:50 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-05-16.01.txt | |
| 16:53:50 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-05-16.01.html | |
| 16:53:50 | opendevmeet | Meeting ended Tue Aug 5 16:53:50 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:53:50 | Uggla | #endmeeting | |
| 17:09:06 | cardoe | So I know its after the meeting but I just wanted to bring up https://review.opendev.org/c/openstack/nova-specs/+/471815 | |
| 17:31:46 | sean-k-mooney | cardoe: i still think that woudl be good to do, in 2026.1 at this point but its still open because of review banding and process | |
| 17:33:37 | cardoe | So Ironic has implemented a patch that grabs the metadata from nova and rewrites it to add that data and then ultimately writes that to disk. | |
| 17:34:42 | sean-k-mooney | that was added for another reason i belive | |
| 17:34:51 | sean-k-mooney | but yes they have some logic for updatign the config drive | |
| 17:35:11 | sean-k-mooney | that for port_groups in general rather then bonding specificly i think | |
| 17:35:32 | sean-k-mooney | or perhaps its for bonding rather then for vlan trunking | |
| 17:35:49 | sean-k-mooney | i vagly recall the patch but not the details | |
| 17:36:36 | sean-k-mooney | cardoe: https://bugs.launchpad.net/ironic/+bug/2106073 | |
| 17:37:13 | sean-k-mooney | which which was adress by https://review.opendev.org/c/openstack/ironic/+/946677 | |
| 17:39:29 | sean-k-mooney | cardoe: it looks like they have chosen to use the uuid for the link id https://review.opendev.org/c/openstack/ironic/+/946677/29/ironic/conductor/configdrive_utils.py#295 | |
| 17:39:39 | sean-k-mooney | even if that may brake some usescases | |
| 17:39:49 | sean-k-mooney | that effecitvly what i was suggesting doing too | |
| 17:40:00 | cardoe | Well I can update the spec as well. | |
| 17:41:08 | sean-k-mooney | ack they have some examples of what it will looklike in tehre unit tests https://review.opendev.org/c/openstack/ironic/+/946677/29/ironic/tests/unit/conductor/test_configdrive_utils.py#169 | |
| 17:55:07 | cardoe | I'm happy to do whatever you guys would like to see to get it landed. | |
| 17:55:49 | cardoe | I'm merely trying to show users in my company and then at another company (where some former co-workers have gone) that they need to be engaging with upstream instead of downstream patches. | |
| 17:56:14 | cardoe | Which has morphed into me finding that spec and series which is from another company. And the written patches are written by yet another company. | |
| 17:56:59 | cardoe | While my company engages with upstream (hi I'm here) there's other orgs within that don't necessarily. | |
| 17:57:08 | cardoe | Then these other two companies aren't engaging at all. | |
| 17:57:38 | cardoe | You want devs and contributors, well I gotta convince these companies that it's not pointless to engage upstream on features. | |
| 18:10:06 | sean-k-mooney | cardoe: ack Uggla fyi ^ | |
| 18:10:43 | sean-k-mooney | cardoe: its not pointless but someone aslo need to actully do the work and chapiaion the idea. you are promoting it well | |
| 18:11:53 | cardoe | I picked this feature cause I thought it'd be the easiest since it had a spec, an implementation, it had tempest tests for nova, neutron, and ironic | |
| 18:13:09 | sean-k-mooney | right the context that is around it is many core reviewer have been feeling burn out due to the numebr of feature thaty are bign asked to review so it was propsoed that we shoudl approve less specs but try to activlly land the ones we do approve | |
| 18:13:37 | sean-k-mooney | a side effect of that was suggestin that cores shoudl only +2 a spec if they intend to spend time reviewin it | |
| 18:14:09 | sean-k-mooney | that why this didnt progress. its obvious that there is some interest in doing his | |
| 18:14:18 | sean-k-mooney | so i think it could happen next cycle | |
| 18:25:57 | cardoe | okay | |
| 21:56:54 | opendevreview | Callum Dickinson proposed openstack/nova master: Fix image ID in libvirt metadata when unshelving https://review.opendev.org/c/openstack/nova/+/942973 | |
| 21:56:55 | opendevreview | Callum Dickinson proposed openstack/nova master: Add image meta to libvirt XML metadata https://review.opendev.org/c/openstack/nova/+/942766 | |
| 21:56:55 | opendevreview | Callum Dickinson proposed openstack/nova master: Add more flavor metadata to libvirt guest XML https://review.opendev.org/c/openstack/nova/+/942974 | |
| 22:00:32 | Callum027 | sean-k-mooney: Morning, thanks for getting in touch, I've rebased and adopted the suggestions you made to my patches | |
| 22:03:42 | sean-k-mooney | Callum027: thanks, im just wrappiping for today, i proably shoudl have stop about 4 hours ago :) but ill take alook again tomorrow once we get some ci results | |
| 22:03:58 | Callum027 | No worries, have a good evening | |
| 22:04:02 | sean-k-mooney | o/ | |
| 23:06:46 | melwitt | working on code near the server group late affinity check I noticed it looks like there has been a regression in the error handling of the check due to a past bug fix that changed what exception the late check raises https://bugs.launchpad.net/nova/+bug/2119578 | |
| 23:07:10 | melwitt | I just filed a bug to capture it | |
| #openstack-nova - 2025-08-06 | |||
| 06:36:43 | auniyal | https://review.rdoproject.org/r/c/openstack/nova-distgit/+/58076 | |
| 06:36:43 | auniyal | hi sean-k-mooney, will you have access to merge this in nova-disgit | |