Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-01-12
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
17:01:58 tkajinam that's something I expect to be covered by that statement
17:02:55 sean-k-mooney tkajinam: i think the main issue is the copy tiem if your using a raw image. obvioulsy there is no copy invoveld for qcow since we just share the backing file form the cache outise of the initial spawn
17:03:41 jayaanand We want to leverage copy on write technology from ONTAP
17:03:50 tkajinam ok but I think that can be also eased by image cache volume in cinder/glance I guess
17:03:55 jayaanand Instead of qcow2 format
17:04:48 sean-k-mooney i think we will need more context on hwo that work and if tis a generic feature in nfs itslef or some propeirty extnsion
17:04:51 jayaanand We explored cinder volumes. Direct ONTAP volumes give better performance
17:05:30 sean-k-mooney but you said using nfs right so taht woudl still just be a file of some form on disk
17:05:41 sean-k-mooney well a file on a file system
17:05:56 jayaanand It's propeirty on top of NFS
17:06:13 sean-k-mooney right os that also problematic
17:06:25 jayaanand Yes NFS on compute node
17:06:51 jayaanand File on ONTAP with better copy on write
17:07:40 sean-k-mooney ack can you create a draft spec, it does not have to be compelte with your problemstatemen use cases and any relvente context/info on the feature
17:07:49 tkajinam https://specs.openstack.org/openstack/nova-specs/
17:08:00 tkajinam https://specs.openstack.org/openstack/nova-specs/readme.html
17:08:22 jayaanand Sure, i will create, thank you for the advice
17:08:53 Uggla Cool, we are already overtime, last minute thing to add ? If not then we will close.
17:09:03 jayaanand Need to understand how right OS that is problematic?
17:09:38 womax I had something I wanted to talk about but it can wait for next week
17:09:58 womax and i think it can be discussed outside of meetings
17:10:07 Uggla womax thanks, if you can update the agenda, so it will be identified.
17:10:10 jayaanand Sure
17:10:24 womax Uggla: ok i'll do that
17:11:15 Uggla Thanks for joining this meeting. Closing now.
17:11:24 Uggla #endmeeting
17:11:24 opendevmeet Meeting ended Mon Jan 12 17:11:24 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:11:24 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-12-16.05.html
17:11:24 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-12-16.05.txt
17:11:24 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-12-16.05.log.html
17:12:17 jayaanand Thank you
17:17:48 sean-k-mooney jayaanand: googleign thie a liitle ONTAP wafl filestiem when exported vis nfs 4.2 can transparently supprot servier side cloning when you use qemu-im or cp with the --reflink link flag
17:18:09 sean-k-mooney provided you have ONTAP 9.8
17:19:20 jayaanand true, ONTAP handles RAW with native compression and dedupe. this with avoid double virtualization
17:20:04 sean-k-mooney so im wonderign if the flat backend woudl be enough for your usecase
17:20:07 sean-k-mooney or raw
17:20:34 sean-k-mooney if we ensure nova propelry uses that feature when nfs 4.2 is used
17:20:52 jayaanand raw is better handled at ONTAP
17:21:29 sean-k-mooney sure but we already supprot raw format
17:21:30 jayaanand file is facade hear, internally it is RAW at WAFL
17:21:52 sean-k-mooney what im saying is it may be possible to not add a new backend at all
17:22:08 sean-k-mooney and simple use the more efficnet copy method when tis supproted by the file systems

Earlier   Later