| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-01-12 | |||
| 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 | |
| 17:22:11 | jayaanand | we won't introduce new format. we will user RAW with ONTAP copy on write capabilities | |
| 17:22:55 | jayaanand | we will delegate any clone operation to ONTAP for quick VM creation | |
| 17:23:00 | jayaanand | on top of RAW | |
| 17:23:35 | jayaanand | these are NFS files at ONTAP on top of FlexGroup | |
| 17:24:01 | 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:18 | 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:31 | 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:32 | sean-k-mooney | when doign the copy fo the image | |
| 17:25:11 | sean-k-mooney | well nfs v3 supprot is deprecated in general | |
| 17:25:23 | sean-k-mooney | we ahve recommend 4.2 or a bove for many years now | |
| 17:25:46 | sean-k-mooney | that recomendation orgianlly came form the qemu storage maintaienrs | |
| 17:25:58 | jayaanand | docs.netapp.com/us-en/ontap/nfs-admin/ontap-support-nfsv42-concept.html | |
| 17:26:01 | sean-k-mooney | i.e. to move to v4+ due to lockign issues | |
| 17:26:28 | jayaanand | Max, almost all of our customers on NFS 4+ | |
| 17:26:39 | jayaanand | you can look into your specific issue | |
| 17:26:58 | MaxLamprecht[m] | Yes we also use nfs4.2 :) | |
| 17:27:44 | 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:54 | sean-k-mooney | http://nfsv4bat.org/Documents/ConnectAThon/2010/ss-copy-spec.pdf that netaps presetion on the feature form 2010 | |
| 17:28:24 | sean-k-mooney | but maybe it never got enabeld or is behind a config flag | |
| 17:30:10 | jayaanand | For direct storage on the ONTAP backend, QCOW2 images are automatically converted to the raw format | |
| 17:31:03 | jayaanand | https://www.netapp.com/media/10720-tr-4067.pdf | |
| 17:31:54 | 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:32:29 | sean-k-mooney | so you woudl set https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.force_raw_images to true | |
| 17:32:31 | jayaanand | https://www.irccloud.com/pastebin/OCDzzgTM/ | |
| 17:32:47 | sean-k-mooney | and images-type=raw or images_type=flat | |
| 17:36:01 | jayaanand | ok, let me check if reflink will trigger clone at ONTAP | |
| 17:36:25 | jayaanand | i will explore and share my findings | |
| 17:36:30 | sean-k-mooney | ack | |
| 17:37:10 | 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:38:52 | jayaanand | sure, we want to use RAW format to take advantage of propitiatory de-dupe, compression and COW | |
| 17:39:38 | jayaanand | and avoid double virtualization at storage layer and save VM cycles for QCOW2 maintenance | |
| 18:05:59 | 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:06:12 | 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:25:09 | 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 | |
| #openstack-nova - 2026-01-13 | |||
| 02:39:56 | mkuroha | Hi gibi, sorry to bother you just after you got back from PTO. I’ve updated this patch based on your feedback. Please take a look and share any comments when you have time. https://review.opendev.org/c/openstack/nova/+/948304 | |
| 03:01:17 | seyeongkim | could someone please review this patch or give me any advices about the approch? thanks so much. https://review.opendev.org/c/openstack/nova/+/963665 | |
| 08:52:55 | gibi | sambork: o/ I'm not sure you saw gmaan's post merge comments on the conductor eventlet series. https://review.opendev.org/c/openstack/nova/+/962478 I think it worth checking if there are dead code / missing cleanup based on his comments in that patch | |
| 08:55:53 | sambork | hey gibi, thanks for pointing out this one! yeah I will check them ! | |
| 09:30:23 | bauzas | Uggla: fancy mentioning today as implementation review day ? :) | |
| 09:39:33 | Uggla | bauzas, you are right, I forgot about it yesterday. | |
| 09:40:18 | bauzas | Uggla: can I use https://etherpad.opendev.org/p/nova-2026.1-status as a base for reviewing patches | |
| 09:40:20 | bauzas | ? | |
| 09:43:05 | Uggla | bauzas, I still not updated it (gonna do it). So unfortunately not. But you can have a look at r_taken's https://blueprints.launchpad.net/nova/+spec/generalize-sev-code patch | |
| 09:43:16 | bauzas | thanks | |
| 09:43:41 | bauzas | and I also said to tkajinam that I was wanting to review his patches, tkajinam any first ones I should look at ? | |
| 09:47:17 | bauzas | Uggla: can you please set https://blueprints.launchpad.net/nova/+spec/generalize-sev-code to approved as we agreed at the PTG ? | |
| 09:54:07 | Uggla | bauzas, yep | |
| 11:04:27 | tkajinam | bauzas, all of my patches are in single chain so please start from https://review.opendev.org/c/openstack/nova/+/969263 (I triggered recheck because the failure in threading job looks unrelated (and has never seen before) | |
| 11:05:01 | tkajinam | the first one is the preparation work which extends the existing functional test coverage so I believe it's not very controversial :-) | |
| 13:45:34 | sean-k-mooney | seyeongkim: so that is a feature rather then a bug. its alos possibel to specify the boot order via teh block device mappings today | |
| 13:50:13 | sean-k-mooney | lookign at the bug report this does not seam to be a nova bug | |