Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-01-12
16:20:32 Uggla #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned
16:20:48 Uggla #info still 20 remaining atm.
16:21:00 Uggla #topic Stable Branches
16:21:04 sean-k-mooney jayaanand: we shoudl dicsuss that at the end but that will need a spec and it may be contoverial
16:21:13 sean-k-mooney Uggla: for openapi
16:21:13 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Extend functional test coverage of UEFI boot guests https://review.opendev.org/c/openstack/nova/+/969263
16:21:14 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Add capability to load loader and nvram from xml https://review.opendev.org/c/openstack/nova/+/969086
16:21:14 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Add basic xml generation for firmware auto selection https://review.opendev.org/c/openstack/nova/+/969085
16:21:15 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Use firmware auto-selection by libvirt https://review.opendev.org/c/openstack/nova/+/969132
16:21:15 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Add capability to load ssm feature from existing xml https://review.opendev.org/c/openstack/nova/+/969131
16:21:21 elodilles #info stable gates seem to be in good state
16:21:28 sean-k-mooney I got through all the serise before going on pto
16:21:29 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:21:41 elodilles that's all from me about stable
16:21:50 gmaan stephenfin: yeah, its on me. I will try to review as much and soon i can
16:21:54 gmaan sean-k-mooney: ^^
16:21:59 tkajinam elodilles, I wonder if we merged all of the backports of the os-vif job update ?
16:22:14 elodilles tkajinam: not yet
16:22:16 sean-k-mooney gmaan: no worries ill loop back as needed
16:22:23 gmaan ++
16:22:40 tkajinam elodilles, ah, ok
16:22:40 elodilles tkajinam: https://review.opendev.org/q/topic:fix-zuul-config-error-nova
16:23:03 elodilles ^^^ the patches need stable core reviews o:)
16:23:11 tkajinam ^^^ it would be better to merge these before stable branches are still stable :-)
16:23:19 tkajinam s/before/while/
16:23:22 Uggla sorry I was bit fast on the openapi topic. glad if gmaan, you can review these patches.
16:24:03 Uggla sean-k-mooney, thanks for the review, hopefully we could finish this cycle.
16:24:07 tkajinam Uggla, no problem
16:25:18 Uggla something more you'd like to add on either openapi or stable branches ?
16:26:02 sean-k-mooney we can likely move on. ill take a look at the zuul erros
16:26:15 Uggla #topic vmwareapi 3rd-party CI efforts Highlights
16:26:48 fwiesel Hi, so I have finally hooked up the oslo.vmware repo to the CI... sorry for the oversight.
16:27:56 fwiesel Still working on a patch to fix the final problems (https://review.opendev.org/c/openstack/nova/+/941095), but I did run into another bug in Cinder vmdk driver there.
16:27:57 sean-k-mooney i know gibi was intersted in feedback on the eventlet related patches
16:28:17 sean-k-mooney for oslo.vmware
16:28:41 fwiesel Yes, I retriggered the job on his patch and provided a comment that it didn't cause any regressions.
16:29:04 sean-k-mooney awsome
16:29:32 fwiesel So, hopefully I get another cinder patch in and then we should see tempest succeed.
16:29:36 fwiesel That's from my side.
16:30:25 Uggla thx fwiesel.
16:32:06 Uggla skipping next point about eventlet removal because gibi was on pto. And as he mentioned earlier, nothing new yet on that side.
16:32:19 Uggla #topic Open discussion
16:32:55 Uggla jayaanand, please go ahead.
16:33:04 nicolairuckel I'd like to talk about my NVRAM patch later
16:33:52 Uggla nicolairuckel please go ahead then jayaanand.
16:34:50 nicolairuckel https://review.opendev.org/c/openstack/nova/+/959682
16:34:54 nicolairuckel It's about that patch.
16:35:22 nicolairuckel tkajinam had some comments and I wasn't sure if my answers really addressed all of his concerns.
16:35:42 nicolairuckel And I was wondering if there's anything still needed for a (hopefully) final review.
16:36:07 jayaanand Sure
16:36:32 jayaanand We are planning to implement NetApp FlexGroup Backend for Ceph-like Ephemeral Storage Performance on NFS similar to Ceph by overriding RAW format
16:37:09 jayaanand Can you please let us know if we are in right direction
16:37:15 nicolairuckel After that I'd like to work on fixing the behaviour for cold migration. I think tkajinam is implementing at least some parts of that already so it would be nice if we'd be able to coordinate that a bit.
16:37:33 sean-k-mooney jayaanand: let finish the nvram topic first
16:37:40 tkajinam nicolairuckel, not really, but if we want to address that (detect change in nvram template and clear var) we have to import the machanism to detect existing nvram template from my change, and we likely have to clear it during cold migration
16:38:08 sean-k-mooney tkajinam: so we woudl liek to backprot the nvram fixes if we can
16:38:13 tkajinam nicolairuckel, the core problem is that cold migration provides no way to tell which nvram template is used before migration, because xml is generated from scratch at the destination and we don't pass the previous xml
16:38:27 sean-k-mooney so ideally we want to fix that first with as littel depency on the firmeware detection serise
16:39:04 nicolairuckel And then after tkajinam's patch, it should be possible to fix the cold migration, correct? So it makes sense to wait for that.
16:39:09 sean-k-mooney tkajinam: for cold migration we will need to handel that yes. that may not be backprotable
16:39:21 sean-k-mooney but at lest the hard reboot case shoudl be simpler.
16:39:54 tkajinam nicolairuckel, no. it provides only base code to detect required reset for hard-reboot (and start) only
16:40:14 sean-k-mooney so for hard reboot we should not be reseting the nvram file ever
16:40:59 nicolairuckel tkajinam had an example with secure_boot where it needs to be reset in the comments.
16:41:10 sean-k-mooney i guess we coudl create it if and onloy if it is not present
16:41:26 nicolairuckel https://review.opendev.org/c/openstack/nova/+/959682/comments/ae045d85_9e58a5a5
16:41:33 sean-k-mooney in case it got deleted out of band but we should expect it to exit in general when hard rebooting
16:42:09 sean-k-mooney why woudl secure boot requrie it
16:42:47 tkajinam sean-k-mooney, yeah but the core problem is that nvram code may be changed, because nova always re-select it when an instance is started ...
16:43:42 sean-k-mooney so wheter a vms uses securie boot is ment to be fixed at the tiem teh vm is first created
16:43:57 sean-k-mooney even with os_secure_boot=optional
16:44:14 dansmith isn't this stuff that can be discussed on the review?
16:44:31 tkajinam yes
16:44:49 dansmith both because we have a big audience here, but also these sorts of reasoning things seem best to capture in the gerrit history
16:45:20 sean-k-mooney well the didcion is ther form last year
16:45:47 sean-k-mooney i disagree with tkajinam usecase however but we can contiue to dicuss it ther
16:46:01 dansmith I've reviewed the patch a little in the past, but I think that we probably need sean-k-mooney to help ack the workflow and lifecycle constraints (and maybe tkajinam) but.. that is best preserved in the gerrit comments for other reviewers I think
16:46:03 nicolairuckel sorry, I just brought it up here because I didn't get any replies on the review anymore and wanted to know if there's anything I'd need to do before my patch can get merged.
16:46:24 nicolairuckel But I'd be happy to discuss it there. :)
16:46:46 dansmith nicolairuckel: yeah it's fine to raise the awareness here, I'm just saying I don't think we need to have this full discussion in the meeting
16:46:52 dansmith just MHO
16:47:03 nicolairuckel I'll mark the comment as unresolved now and I guess then we can move on for now.
16:47:30 dansmith and also,
16:47:56 dansmith if it's this complicated, perhaps we should have a spec explaining the theory of when we want to nuke NVRAM, not, and the constraints around firmware that come with it
16:48:18 dansmith because that's helpful for the review, otherwise I'm left kinda helpless, sure that I don't know all these intricacies and thus unable to approve
16:48:39 sean-k-mooney for me that is simply its baisclly never ok to od it unless perhaps rebuild
16:48:57 dansmith that would be my assumption as well
16:49:00 sean-k-mooney even then its qutionable as ti will brake bitlocker
16:49:05 dansmith basically, like a real computer with actual NVRAM
16:49:13 sean-k-mooney yep
16:49:57 sean-k-mooney we dont currently snapshto the nvram so i dont think rebuild shoudl recreated it. however it might be reasonable fi rebuilding to a diffent image entirly.
16:50:20 sean-k-mooney my general hope was we woudl fix preseving it for hard reboot in the current patch
16:50:31 sean-k-mooney and then adress everything else sperately
16:50:38 dansmith again, this is sounding more like a spec than a bug fix, given it's going to introduce new behavior and affect many operations
16:51:41 sean-k-mooney maybe but to me this was just restorign the behvior we orginally intended
16:51:57 sean-k-mooney but i agree its non trivial and we need to docuemnt the lifecylce
16:52:46 dansmith I didn't ever have intent for this, so don't lump me into that "we".. perhaps you mean what _you_ intended, and that's fine, but regardless it's going to be more of a change from where we are
16:52:56 dansmith especially if we're doing things like only recreating if rebuilding to a different image, etc
16:53:29 sean-k-mooney well that actully more of a a comment on the related vtpm feature rather then nvram
16:53:43 sean-k-mooney we said we wanted to adress both the same way

Earlier   Later