| *** mhen_ is now known as mhen | 02:57 | |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Use ServiceCatalog class for identity v3 API https://review.opendev.org/c/openstack/nova/+/973038 | 05:43 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/nova master: Use ServiceCatalog class for identity v3 API https://review.opendev.org/c/openstack/nova/+/973038 | 05:45 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Use ServiceCatalog class for identity v3 API https://review.opendev.org/c/openstack/nova/+/973038 | 05:57 |
| opendevreview | Fabian Wiesel proposed openstack/nova master: WIP: Re-create volume backed root before destroy https://review.opendev.org/c/openstack/nova/+/941095 | 09:23 |
| opendevreview | Fabian Wiesel proposed openstack/nova master: WIP: Re-create volume backed root before destroy https://review.opendev.org/c/openstack/nova/+/941095 | 10:46 |
| opendevreview | Fabian Wiesel proposed openstack/nova master: WIP: Re-create volume backed root before destroy https://review.opendev.org/c/openstack/nova/+/941095 | 10:51 |
| opendevreview | Fabian Wiesel proposed openstack/nova master: WIP: Re-create volume backed root before destroy https://review.opendev.org/c/openstack/nova/+/941095 | 10:52 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Use ServiceCatalog class for identity v3 API https://review.opendev.org/c/openstack/nova/+/973038 | 12:30 |
| opendevreview | Masanori Kuroha proposed openstack/nova master: Copy applied provider config https://review.opendev.org/c/openstack/nova/+/948304 | 14:03 |
| opendevreview | Max Harmathy proposed openstack/nova master: Fix crash due to access to uninitialized variable https://review.opendev.org/c/openstack/nova/+/973103 | 14:19 |
| gibi | Uggla: I will be pretty absent during our today's meeting. Nothing to report from eventlet as I was on PTO and haven't loaded context yet. | 15:44 |
| gibi | I will read back later. Sorry. | 15:44 |
| Uggla | gibi no worries thanks for letting me know. | 15:53 |
| dansmith | so... meeting or no? | 16:03 |
| Uggla | yep | 16:04 |
| Uggla | #startmeeting nova | 16:05 |
| opendevmeet | Meeting started Mon Jan 12 16:05:31 2026 UTC and is due to finish in 60 minutes. The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:05 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:05 |
| opendevmeet | The meeting name has been set to 'nova' | 16:05 |
| Uggla | Hello everyone | 16:05 |
| dansmith | o/ | 16:05 |
| fwiesel | o/ | 16:05 |
| Uggla | Sorry I'm a little late today. | 16:05 |
| sean-k-mooney | o/ | 16:05 |
| gmaan | o/ | 16:05 |
| tkajinam | o/ | 16:06 |
| nicolairuckel | o/ | 16:06 |
| elodilles | o/ | 16:06 |
| bauzas | o/ (late due to other priorities) | 16:07 |
| Uggla | Let's start | 16:08 |
| Uggla | #topic Bugs (stuck/critical) | 16:08 |
| Uggla | #info No Critical bug | 16:08 |
| Uggla | #topic Gate status | 16:08 |
| Uggla | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:09 |
| Uggla | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:09 |
| Uggla | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status | 16:09 |
| Uggla | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:09 |
| Uggla | #info Please try to provide a meaningful comment when you recheck | 16:09 |
| Uggla | I have no seen something special about the gates. | 16:10 |
| Uggla | Something you'd like to mention ? | 16:10 |
| sean-k-mooney | i saw sopme tox timesout last week | 16:11 |
| sean-k-mooney | not sure if they are still happeing | 16:11 |
| sean-k-mooney | so maybe just keep an eye out. i think in some case the 3.12 jobs were incorrectly compiling python with pyvenv | 16:12 |
| sean-k-mooney | althoguh i have not really looked into that much since it did not seam to be a blanket failure | 16:12 |
| gmaan | I think I saw in tox cover job last week but rest other were ok | 16:13 |
| sean-k-mooney | ya so lets just keep an eye on it | 16:13 |
| tkajinam | https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/970973 | 16:13 |
| sean-k-mooney | oh it got fixed | 16:14 |
| tkajinam | I think that py3.12 compiled during jobs is resolved by ^^^ | 16:14 |
| tkajinam | yeah | 16:14 |
| tkajinam | there is also another which migrates py313 to Debian Trixie to avoid pyenv. just fyi. https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/970036 | 16:14 |
| tkajinam | (this is still pending on reviews) | 16:14 |
| sean-k-mooney | ah cool | 16:15 |
| sean-k-mooney | it normally doesnt take that long but it was adding 8 mins to the job that timed out | 16:15 |
| sean-k-mooney | so on a slow node it was wastign time | 16:16 |
| sean-k-mooney | we can probaly move on | 16:16 |
| Uggla | yep thx for the info | 16:17 |
| jayaanand | hi | 16:17 |
| Uggla | #topic Release Planning | 16:17 |
| Uggla | #link https://releases.openstack.org/gazpacho/schedule.html | 16:17 |
| Uggla | #info Nova deadlines are set in the above schedule | 16:17 |
| Uggla | #info 7 weeks before feature freeze | 16:17 |
| Uggla | #info PTG etherpad for 2026.1 is available: https://etherpad.opendev.org/p/nova-2026.1-ptg | 16:17 |
| Uggla | #topic Review priorities | 16:19 |
| Uggla | #link https://etherpad.opendev.org/p/nova-2026.1-status | 16:19 |
| Uggla | ^ still not updated sorry for that. | 16:19 |
| 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:19 |
| Uggla | jayaanand, please wait the open discussion point | 16:20 |
| jayaanand | Sent email to Openstack discussion group | 16:20 |
| jayaanand | Ok | 16:20 |
| Uggla | #topic OpenAPI | 16:20 |
| Uggla | #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned | 16:20 |
| Uggla | #info still 20 remaining atm. | 16:20 |
| Uggla | #topic Stable Branches | 16:21 |
| sean-k-mooney | jayaanand: we shoudl dicsuss that at the end but that will need a spec and it may be contoverial | 16:21 |
| * Uggla giving the mic to elodilles | 16:21 | |
| 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 |
| sean-k-mooney | Uggla: for openapi | 16:21 |
| 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 |
| 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 |
| 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 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Use firmware auto-selection by libvirt https://review.opendev.org/c/openstack/nova/+/969132 | 16:21 |
| elodilles | #info stable gates seem to be in good state | 16:21 |
| sean-k-mooney | I got through all the serise before going on pto | 16:21 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:21 |
| elodilles | that's all from me about stable | 16:21 |
| gmaan | stephenfin: yeah, its on me. I will try to review as much and soon i can | 16:21 |
| gmaan | sean-k-mooney: ^^ | 16:21 |
| * elodilles passing back the mic to Uggla | 16:21 | |
| tkajinam | elodilles, I wonder if we merged all of the backports of the os-vif job update ? | 16:21 |
| elodilles | tkajinam: not yet | 16:22 |
| sean-k-mooney | gmaan: no worries ill loop back as needed | 16:22 |
| gmaan | ++ | 16:22 |
| elodilles | tkajinam: https://review.opendev.org/q/topic:fix-zuul-config-error-nova | 16:22 |
| tkajinam | elodilles, ah, ok | 16:22 |
| elodilles | ^^^ the patches need stable core reviews o:) | 16:23 |
| tkajinam | ^^^ it would be better to merge these before stable branches are still stable :-) | 16:23 |
| tkajinam | s/before/while/ | 16:23 |
| Uggla | sorry I was bit fast on the openapi topic. glad if gmaan, you can review these patches. | 16:23 |
| Uggla | sean-k-mooney, thanks for the review, hopefully we could finish this cycle. | 16:24 |
| tkajinam | Uggla, no problem | 16:24 |
| Uggla | something more you'd like to add on either openapi or stable branches ? | 16:25 |
| sean-k-mooney | we can likely move on. ill take a look at the zuul erros | 16:26 |
| Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | 16:26 |
| * Uggla passing the mic to fwiesel, who seems to have provided patches. | 16:26 | |
| fwiesel | Hi, so I have finally hooked up the oslo.vmware repo to the CI... sorry for the oversight. | 16:26 |
| 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 |
| sean-k-mooney | i know gibi was intersted in feedback on the eventlet related patches | 16:27 |
| sean-k-mooney | for oslo.vmware | 16:28 |
| fwiesel | Yes, I retriggered the job on his patch and provided a comment that it didn't cause any regressions. | 16:28 |
| sean-k-mooney | awsome | 16:29 |
| fwiesel | So, hopefully I get another cinder patch in and then we should see tempest succeed. | 16:29 |
| fwiesel | That's from my side. | 16:29 |
| Uggla | thx fwiesel. | 16:30 |
| 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 |
| Uggla | #topic Open discussion | 16:32 |
| Uggla | jayaanand, please go ahead. | 16:32 |
| nicolairuckel | I'd like to talk about my NVRAM patch later | 16:33 |
| Uggla | nicolairuckel please go ahead then jayaanand. | 16:33 |
| nicolairuckel | https://review.opendev.org/c/openstack/nova/+/959682 | 16:34 |
| nicolairuckel | It's about that patch. | 16:34 |
| nicolairuckel | tkajinam had some comments and I wasn't sure if my answers really addressed all of his concerns. | 16:35 |
| nicolairuckel | And I was wondering if there's anything still needed for a (hopefully) final review. | 16:35 |
| jayaanand | Sure | 16:36 |
| 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:36 |
| jayaanand | Can you please let us know if we are in right direction | 16:37 |
| 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 |
| sean-k-mooney | jayaanand: let finish the nvram topic first | 16:37 |
| 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:37 |
| sean-k-mooney | tkajinam: so we woudl liek to backprot the nvram fixes if we can | 16:38 |
| 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 |
| sean-k-mooney | so ideally we want to fix that first with as littel depency on the firmeware detection serise | 16:38 |
| 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 |
| sean-k-mooney | tkajinam: for cold migration we will need to handel that yes. that may not be backprotable | 16:39 |
| sean-k-mooney | but at lest the hard reboot case shoudl be simpler. | 16:39 |
| tkajinam | nicolairuckel, no. it provides only base code to detect required reset for hard-reboot (and start) only | 16:39 |
| sean-k-mooney | so for hard reboot we should not be reseting the nvram file ever | 16:40 |
| nicolairuckel | tkajinam had an example with secure_boot where it needs to be reset in the comments. | 16:40 |
| sean-k-mooney | i guess we coudl create it if and onloy if it is not present | 16:41 |
| nicolairuckel | https://review.opendev.org/c/openstack/nova/+/959682/comments/ae045d85_9e58a5a5 | 16:41 |
| sean-k-mooney | in case it got deleted out of band but we should expect it to exit in general when hard rebooting | 16:41 |
| sean-k-mooney | why woudl secure boot requrie it | 16:42 |
| 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: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 |
| sean-k-mooney | even with os_secure_boot=optional | 16:43 |
| dansmith | isn't this stuff that can be discussed on the review? | 16:44 |
| tkajinam | yes | 16:44 |
| 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:44 |
| sean-k-mooney | well the didcion is ther form last year | 16:45 |
| sean-k-mooney | i disagree with tkajinam usecase however but we can contiue to dicuss it ther | 16:45 |
| 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 |
| 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 |
| nicolairuckel | But I'd be happy to discuss it there. :) | 16: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 |
| dansmith | just MHO | 16:46 |
| nicolairuckel | I'll mark the comment as unresolved now and I guess then we can move on for now. | 16:47 |
| dansmith | and also, | 16:47 |
| 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:47 |
| 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 |
| sean-k-mooney | for me that is simply its baisclly never ok to od it unless perhaps rebuild | 16:48 |
| dansmith | that would be my assumption as well | 16:48 |
| sean-k-mooney | even then its qutionable as ti will brake bitlocker | 16:49 |
| dansmith | basically, like a real computer with actual NVRAM | 16:49 |
| sean-k-mooney | yep | 16:49 |
| 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:49 |
| sean-k-mooney | my general hope was we woudl fix preseving it for hard reboot in the current patch | 16:50 |
| sean-k-mooney | and then adress everything else sperately | 16:50 |
| 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:50 |
| sean-k-mooney | maybe but to me this was just restorign the behvior we orginally intended | 16:51 |
| sean-k-mooney | but i agree its non trivial and we need to docuemnt the lifecylce | 16:51 |
| 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 |
| dansmith | especially if we're doing things like only recreating if rebuilding to a different image, etc | 16:52 |
| sean-k-mooney | well that actully more of a a comment on the related vtpm feature rather then nvram | 16:53 |
| sean-k-mooney | we said we wanted to adress both the same way | 16:53 |
| sean-k-mooney | and for vtpm we very explcitly wanted to preserve the data across lifecycle operations | 16:53 |
| nicolairuckel | I mean, there were a few bug reports were people expected the behaviour from my patch. | 16:54 |
| sean-k-mooney | lets give the last 5 mins to jayaanand | 16:54 |
| Uggla | guys, can we stop and let some time for jayaanand | 16:54 |
| jayaanand | thank you | 16:54 |
| 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 |
| 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 |
| 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:55 |
| jayaanand | This cow operations will be taken care at storage | 16:56 |
| 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:56 |
| jayaanand | Ok, Has anyone explored or implemented storage-side cloning for other NFS vendors? | 16:57 |
| sean-k-mooney | no not in nova | 16:57 |
| sean-k-mooney | we do not creat vendor specific backend in nova in general | 16:57 |
| 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 |
| jayaanand | Ok, concerns is any architectural red flags with this approach in the Nova driver? NFS Ephemeral volumes | 16:58 |
| 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 |
| 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 |
| dansmith | yes, I also don't really want to be adding new image backends to the current implementation | 16:59 |
| bauzas | agreed | 17:00 |
| * dansmith has to run | 17:00 | |
| 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:00 |
| jayaanand | Ok, we have multiple customers looking for this feature... What is way out?any suggestions | 17:01 |
| sean-k-mooney | i think we need to know what the problem statement is first | 17:01 |
| 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 |
| sean-k-mooney | perhaps there si a way to adress that without requriing a new backend | 17:01 |
| tkajinam | that's something I expect to be covered by that statement | 17:01 |
| 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:02 |
| jayaanand | We want to leverage copy on write technology from ONTAP | 17:03 |
| tkajinam | ok but I think that can be also eased by image cache volume in cinder/glance I guess | 17:03 |
| jayaanand | Instead of qcow2 format | 17:03 |
| 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 |
| jayaanand | We explored cinder volumes. Direct ONTAP volumes give better performance | 17:04 |
| sean-k-mooney | but you said using nfs right so taht woudl still just be a file of some form on disk | 17:05 |
| sean-k-mooney | well a file on a file system | 17:05 |
| jayaanand | It's propeirty on top of NFS | 17:05 |
| sean-k-mooney | right os that also problematic | 17:06 |
| jayaanand | Yes NFS on compute node | 17:06 |
| jayaanand | File on ONTAP with better copy on write | 17:06 |
| 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 |
| tkajinam | https://specs.openstack.org/openstack/nova-specs/ | 17:07 |
| tkajinam | https://specs.openstack.org/openstack/nova-specs/readme.html | 17:08 |
| jayaanand | Sure, i will create, thank you for the advice | 17:08 |
| Uggla | Cool, we are already overtime, last minute thing to add ? If not then we will close. | 17:08 |
| jayaanand | Need to understand how right OS that is problematic? | 17:09 |
| womax | I had something I wanted to talk about but it can wait for next week | 17:09 |
| womax | and i think it can be discussed outside of meetings | 17:09 |
| Uggla | womax thanks, if you can update the agenda, so it will be identified. | 17:10 |
| jayaanand | Sure | 17:10 |
| womax | Uggla: ok i'll do that | 17:10 |
| Uggla | Thanks for joining this meeting. Closing now. | 17:11 |
| Uggla | #endmeeting | 17:11 |
| 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 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-12-16.05.html | 17:11 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-12-16.05.txt | 17:11 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-12-16.05.log.html | 17:11 |
| jayaanand | Thank you | 17:12 |
| 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:17 |
| sean-k-mooney | provided you have ONTAP 9.8 | 17:18 |
| jayaanand | true, ONTAP handles RAW with native compression and dedupe. this with avoid double virtualization | 17:19 |
| sean-k-mooney | so im wonderign if the flat backend woudl be enough for your usecase | 17:20 |
| sean-k-mooney | or raw | 17:20 |
| sean-k-mooney | if we ensure nova propelry uses that feature when nfs 4.2 is used | 17:20 |
| jayaanand | raw is better handled at ONTAP | 17:20 |
| sean-k-mooney | sure but we already supprot raw format | 17:21 |
| jayaanand | file is facade hear, internally it is RAW at WAFL | 17:21 |
| sean-k-mooney | what im saying is it may be possible to not add a new backend at all | 17:21 |
| sean-k-mooney | and simple use the more efficnet copy method when tis supproted by the file systems | 17:22 |
| jayaanand | we won't introduce new format. we will user RAW with ONTAP copy on write capabilities | 17:22 |
| jayaanand | we will delegate any clone operation to ONTAP for quick VM creation | 17:22 |
| jayaanand | on top of RAW | 17:23 |
| jayaanand | these are NFS files at ONTAP on top of FlexGroup | 17:23 |
| sean-k-mooney | right the feedback im providieng is im not sure that we will accpate a vendor speciics storage backend in nova | 17:24 |
| sean-k-mooney | and im tryign to understand if we can achive the same thing by jsut doing "cp --reflink=always source.raw destination.raw" | 17:24 |
| MaxLamprecht[m] | Interestingly I heard yesterday also about the nfs4.2 native server-side-copy/file-cloning feature. Sadly ONTAP 9.16 currently returns NFS4 error not supported. I guess it‘s not implemented by netapp or hidden by some config flag or so. | 17:24 |
| sean-k-mooney | when doign the copy fo the image | 17:24 |
| sean-k-mooney | well nfs v3 supprot is deprecated in general | 17:25 |
| sean-k-mooney | we ahve recommend 4.2 or a bove for many years now | 17:25 |
| sean-k-mooney | that recomendation orgianlly came form the qemu storage maintaienrs | 17:25 |
| jayaanand | docs.netapp.com/us-en/ontap/nfs-admin/ontap-support-nfsv42-concept.html | 17:25 |
| sean-k-mooney | i.e. to move to v4+ due to lockign issues | 17:26 |
| jayaanand | Max, almost all of our customers on NFS 4+ | 17:26 |
| jayaanand | you can look into your specific issue | 17:26 |
| MaxLamprecht[m] | Yes we also use nfs4.2 :) | 17:26 |
| jayaanand | we tried "if we can achive the same thing by jsut doing "cp --reflink=always source.raw destination.raw""... this is introducing conversion overhead at ONTAP | 17:27 |
| sean-k-mooney | http://nfsv4bat.org/Documents/ConnectAThon/2010/ss-copy-spec.pdf that netaps presetion on the feature form 2010 | 17:27 |
| sean-k-mooney | but maybe it never got enabeld or is behind a config flag | 17:28 |
| jayaanand | For direct storage on the ONTAP backend, QCOW2 images are automatically converted to the raw format | 17:30 |
| jayaanand | https://www.netapp.com/media/10720-tr-4067.pdf | 17:31 |
| sean-k-mooney | ok but i am not suggestign you woudl use qcow im suggestign you configre nova to use raw format but when we copy the raw file from the casche we woudl do that with --reflink so that there would nto be a data copy | 17:31 |
| sean-k-mooney | so you woudl set https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.force_raw_images to true | 17:32 |
| jayaanand | https://www.irccloud.com/pastebin/OCDzzgTM/ | 17:32 |
| sean-k-mooney | and images-type=raw or images_type=flat | 17:32 |
| jayaanand | ok, let me check if reflink will trigger clone at ONTAP | 17:36 |
| jayaanand | i will explore and share my findings | 17:36 |
| sean-k-mooney | ack | 17:36 |
| sean-k-mooney | simply supproting a generic nfs feature like server side copies would be a much smaller chnage if that is suffeient to fullfile the usecase | 17:37 |
| jayaanand | sure, we want to use RAW format to take advantage of propitiatory de-dupe, compression and COW | 17:38 |
| jayaanand | and avoid double virtualization at storage layer and save VM cycles for QCOW2 maintenance | 17:39 |
| opendevreview | sean mooney proposed openstack/nova master: Support os-vif TAP pre-creation for OVS/OVN ports https://review.opendev.org/c/openstack/nova/+/973149 | 18:05 |
| opendevreview | sean mooney proposed openstack/os-vif master: Add TAP device pre-creation support for OVS/OVN https://review.opendev.org/c/openstack/os-vif/+/971231 | 18:06 |
| opendevreview | sean mooney proposed openstack/nova master: Support os-vif TAP pre-creation for OVS/OVN ports https://review.opendev.org/c/openstack/nova/+/973149 | 18:25 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!