Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-08-05
16:24:04 jssfr yes :)
16:24:06 melwitt yes
16:24:07 dansmith okay
16:24:26 dansmith ah I see yes, okay
16:24:57 sean-k-mooney so we have a number of placess we undefine the vm today wher the data shoudl not be deleted, hard-reboot is one but also some volume operations require use to temporlly undefien the domain
16:25:47 melwitt we are thinking about, how to fix this for older versions. the flag addition could be technically seen as a "feature" but IMHO the impact is quite significant and personally I would think about backporting the flag fix to older versions that could be reasonably expected to use libvirt >= 8.9.0 where the flag was introduced
16:26:13 melwitt wondering what others think of this
16:26:37 jssfr I think a backport would be quite appropriate
16:26:37 dansmith shifting behaviors in a library that we have to account for is not a feature, IMHO
16:26:44 jssfr and we are going to backport to at least 2024.1 anyway
16:27:15 jssfr so we could contribute those backported patches at least.
16:27:27 sean-k-mooney dansmith: the wrinkel is libvirt uncondtionally delete the data when we added vtpm supprot and the option to preseve it was added 2 years later
16:27:44 dansmith yeah understand
16:28:04 sean-k-mooney with that said the didnt really document that which is partly why we missed it but i agre we shoudl not require a feature to "do the write thign"
16:28:05 jssfr sean-k-mooney, so you're saying it's not shifting behaviour in libvirt, but simply a bug which existed since forever but which nobody noticed?
16:28:30 sean-k-mooney jssfr: yes, however that does not mean i belive we shoudl consider it a feature
16:28:51 sean-k-mooney i supprot the idea of fixing this condtional on the libvirt verison
16:28:54 dansmith it's shifting behavior and our failure to account for it is a bug not a feature
16:28:55 jssfr (I get the impression that "feature" versus "bug" is an important distinction here, but I'm not sure why. backporting/support policies?)
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.

Earlier   Later