| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-01-12 | |||
| 16:19:28 | Uggla | ^ still not updated sorry for that. | |
| 16:19:50 | jayaanand | I am from NetApp. We are planning to implement FlexGroup Backend for Ceph-like Ephemeral Storage Performance on NFS similar to Ceph by overriding RAW format | |
| 16:20:09 | Uggla | jayaanand, please wait the open discussion point | |
| 16:20:12 | jayaanand | Sent email to Openstack discussion group | |
| 16:20:19 | jayaanand | Ok | |
| 16:20:22 | Uggla | #topic OpenAPI | |
| 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 | |