Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-08-05
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.
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

Earlier   Later