| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-01-12 | |||
| 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 | |
| 16:53:59 | sean-k-mooney | and for vtpm we very explcitly wanted to preserve the data across lifecycle operations | |
| 16:54:12 | nicolairuckel | I mean, there were a few bug reports were people expected the behaviour from my patch. | |
| 16:54:41 | sean-k-mooney | lets give the last 5 mins to jayaanand | |
| 16:54:49 | Uggla | guys, can we stop and let some time for jayaanand | |
| 16:54:51 | jayaanand | thank you | |
| 16:55:14 | 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:55:15 | sean-k-mooney | jayaanand: if i understand your propsoal form the list you want to intoduce nfs awarenes to the image_types backend by adding a new backend | |
| 16:55:40 | dansmith | jayaanand: I dunno what "override RAW" means, but that's almost certainly not going to fly.. either way, we need a detailed spec proposed to review to explain what you're planning and then we can review | |
| 16:56:04 | jayaanand | This cow operations will be taken care at storage | |
| 16:56:06 | dansmith | we're not going to get into the details of that in a meeting, and certainly not with five minutes left, until we have some context to build | |
| 16:57:18 | jayaanand | Ok, Has anyone explored or implemented storage-side cloning for other NFS vendors? | |
| 16:57:31 | sean-k-mooney | no not in nova | |
| 16:57:43 | sean-k-mooney | we do not creat vendor specific backend in nova in general | |
| 16:58:19 | sean-k-mooney | so for us to supprt that in nova we woudll ideally want ti wot work for any generic nfs server | |
| 16:58:23 | jayaanand | Ok, concerns is any architectural red flags with this approach in the Nova driver? NFS Ephemeral volumes | |
| 16:59:07 | sean-k-mooney | the main concern with adding a nfs images_type backend is there is a lot fo existing technial debt in that part of the code base | |
| 16:59:14 | dansmith | yes, I have red flag concerns because of what sean-k-mooney said and also because server-side snapshotting of files nova is accessing is already complicated and different when we do it with cinder | |
| 16:59:36 | dansmith | yes, I also don't really want to be adding new image backends to the current implementation | |
| 17:00:17 | bauzas | agreed | |
| 17:00:58 | sean-k-mooney | its something we can try and dicsus about more but if it would only work for netapp that proably not someting we would pursue. we would also need to dicuss how this will be tested in ci. all of witch would be captures in a spec | |
| 17:01:11 | jayaanand | Ok, we have multiple customers looking for this feature... What is way out?any suggestions | |
| 17:01:33 | sean-k-mooney | i think we need to know what the problem statement is first | |
| 17:01:49 | tkajinam | jayaanand, I think the general preference is to use cinder volume in case you want better features. I still don't understand why you really need it within ephemeral volumes | |
| 17:01:52 | sean-k-mooney | perhaps there si a way to adress that without requriing a new backend | |