14:02:26 <jbernard> #startmeeting cinder
14:02:26 <opendevmeet> Meeting started Wed Dec  3 14:02:26 2025 UTC and is due to finish in 60 minutes.  The chair is jbernard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:26 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:26 <opendevmeet> The meeting name has been set to 'cinder'
14:02:40 <jbernard> jungleboyj rosmaita smcginnis tosky whoami-rajat m5z e0ne geguileo eharney jbernard hemna fabiooliveira yuval tobias-urdin adiare happystacker dosaboy hillpd msaravan sp-bmilanov Luzi sfernand simondodsley  zaubea nileshthathagar flelain wizardbit agalica lutimura: courtesy ping
14:02:45 <jbernard> #topic roll call
14:02:47 <jbernard> o/
14:02:50 <Luzi> o/
14:02:52 <rosmaita> o/
14:02:55 <seunghunlee> o/
14:02:56 <sp-bmilanov> o/
14:02:59 <jbernard> #link https://etherpad.opendev.org/p/cinder-gazpacho-meetings
14:03:13 <VolodymyrBoiko[m]> o/
14:03:16 <whoami-rajat> hey
14:04:29 <Anoop_Shukla> hello
14:04:32 <erlon> \o
14:04:57 <nimeshdesai> o/
14:05:36 <opendevreview> Ivan Anfimov proposed openstack/cinder master: Remove installation guide for openSUSE/SLES  https://review.opendev.org/c/openstack/cinder/+/948766
14:06:40 <gireesh> o/
14:06:46 <jbernard> hey everyone, thanks for joining
14:06:59 <jbernard> #topic annoucements / reminders
14:07:05 <jayaanand> hi
14:07:16 <jbernard> not a lot today, but here are a few things
14:07:28 <jbernard> this friday we have our bi-weekly festival of reviews
14:07:59 <jbernard> we updated the format after the PTG and so far they seem quite productive,
14:08:14 <jbernard> please do join if you have cycles and are interested in contributing
14:08:33 <jbernard> info is here:
14:08:36 <jbernard> #link https://etherpad.opendev.org/p/cinder-festival-of-reviews
14:08:59 <jbernard> this week we're planning to focus on spec review, and getting the gazpacho specs in shape
14:09:22 <jbernard> other reminders
14:09:40 <jbernard> followup from the PTG, there are a few patches worth noting:
14:09:55 <jbernard> the VAST driver needs review: https://review.opendev.org/c/openstack/cinder/+/939005
14:10:31 <jbernard> the disk geometry patch has been refactored to support all drivers (per PTG discussion): https://review.opendev.org/c/openstack/cinder/+/658283 (and needs review)
14:10:53 <dakshina> Hi
14:11:36 <jbernard> we maintain a list of patches that need attention here: https://etherpad.opendev.org/p/cinder-gazpacho-reviews
14:12:10 <jbernard> (in addition to normal patches that get submitted to gerrit), in case anyone is in need of ways to contribute
14:13:06 <jbernard> that's all i have at the moment,
14:13:17 <jbernard> eharney: are you around to mention evenetlet?
14:13:23 <jbernard> eventlet, even
14:14:18 <jbernard> otherwise, we can open to discussion
14:14:22 <jbernard> #topic open discussion
14:16:26 <whoami-rajat> I wanted to quickly know (on a high level) where we are on the image encryption work if Luzi is around -- glance team might have some doubts tomorrow and i just wanted a brief overview before i go over the spec
14:16:26 <mhen> o/
14:16:34 <whoami-rajat> or mhen ^
14:17:13 <mhen> patchsets have all been reworked as discussed in the PTG in October
14:17:29 <mhen> i.e. moving "luks" from disk_format to container_format
14:17:40 <mhen> this also simplified the code in Cinder as a side effect
14:18:06 <mhen> because we do not need to rewrite luks to raw to coerce qemu tooling into not converting things
14:18:22 <mhen> (anymore)
14:18:56 <whoami-rajat> so "luks" is now a container inside which a "raw" image fits -- sounds logical
14:19:13 <Anoop_Shukla> whoami-rajat: We have a document review pending about supporting cross-pool caching for accelerated volume creation. We want to start working to support cross-pool caching for NetApp Cinder driver in this release..
14:19:22 <mhen> whoami-rajat: correct
14:19:36 <eharney> does "luks" there cover luksv1 and v2 or is it just v1?
14:19:56 <mhen> just v1 for now, it is part of the metadata to specify the version
14:20:06 <whoami-rajat> Anoop_Shukla, ack, I've partially scanned over it but will need time to complete, meanwhile i think we can start with netapp specific implementation and i can provide my thoughts on Cinder side of details
14:20:44 <Anoop_Shukla> whoami-rajat: Sure. Thanks Rajat. Will be waiting for any comments on this. We will go ahead with implementation from our side.
14:20:58 <mhen> I also added a new scenario test to https://review.opendev.org/c/openstack/barbican-tempest-plugin/+/952699 to make sure that Cinder's existing volume -> image -> volume for encrypted volumes stays functional
14:21:28 <rosmaita> mhen: what did you decide about image compression 9
14:21:36 <rosmaita> (on the cinder upload side)
14:22:09 <mhen> compression and encryption are mutually exclusive as both are container_formats and you can only specify one
14:22:32 <mhen> Cinder will reject any container_format that isn't "luks" for upload-to-image on encrypted volumes
14:22:43 <rosmaita> ok, that makes sense
14:23:01 <mhen> encrypted data isn't well compressible anyway
14:23:06 <mhen> usually
14:24:46 <flelain> o/
14:25:42 <mhen> unrelated to image encryption but while we are here, I want to raise awareness on https://bugs.launchpad.net/cinder/+bug/2133728
14:25:59 <rosmaita> i guess we'll have to be careful on image download, for legacy images that are luks but also compressed
14:26:58 <mhen> rosmaita: I'll note that down and see if I can reproduce this scenario
14:27:24 <jbernard> eharney: i was curious about evenetlet, do we still need anything from oslo?
14:27:27 <rosmaita> great, and thanks for the extensive writeup in that bug
14:28:00 <eharney> jbernard: they have patches up for review in gerrit to fix our multi-backend c-vol problem
14:28:33 <jbernard> eharney: do you think it unblocks us to proceed? all the pieces appear to be ther?
14:29:25 <eharney> it should, i haven't yet confirmed it fully works for c-vol
14:30:23 <jbernard> ok that's good to hear
14:33:19 <jbernard> anything else to cover? we can break early if not
14:33:34 <Anoop_Shukla> We have some questions about the provisioned capacity and allocated capacity reported by Cinder Drivers. There is a documentation that says we need to report the provisioned capacity to be sum of all Volumes which are not snapshots. Is it okay if NetApp driver reports FlexVolume’s (pool container’s) capacities for provisioned capacity? Is it required/recommended to iterate through all LUNs in the Volume to get
14:33:34 <Anoop_Shukla> the provisioned capacity?
14:34:25 <jayaanand> https://www.irccloud.com/pastebin/eAXKSNeu/
14:34:32 <Anoop_Shukla> The above approach would get rid of iterations to get LUNs and Namespace in a FlexVolume and report the used capacity from FlexVolumes. Also improves the overall perf_stats performance.
14:36:01 <Anoop_Shukla> We checked other drivers which are reporting it at the pool container level (eg. aggregate provisioned space).
14:36:42 <Anoop_Shukla> In NetApp’s driver’s case, today we are not discounting the space from Snapshot Volumes so it is anyway inaccurate.
14:37:25 <Anoop_Shukla> Would love to hear opinions on the above.
14:38:33 <rosmaita> Anoop_Shukla: where is the documentation you are referring to?
14:39:03 <jayaanand> https://review.opendev.org/c/openstack/cinder/+/968831 and doc https://specs.openstack.org/openstack/cinder-specs/specs/queens/provisioning-improvements.html
14:42:20 <erlon> @Anoop_Shukla if you get the flexvol values (unless netapp keeps a record of the sum of created volumes ), they will differ from the provisioned capacity definition IIUC
14:43:30 <Anoop_Shukla> As per the definition of provisioned capacity from what I understood the doc says: “This includes not only volumes created by Cinder but also all other existing volumes in that backend, but does not include snapshots.
14:43:44 <erlon> that will affect the scheduling for users relying on the cinder overprovisioning ratios configurations, and potentially get the user in a situation with more provisioned volumes than the planned ratio
14:44:48 <Anoop_Shukla> Which means, if I have a flexvol which is used for creating cinder volumes and also a different use case where a different application which creates luns which are not Cinder Volumes, we are doing wrong aggregation?
14:47:19 <opendevreview> Merged openstack/cinder master: image_utils: Detect missing device before calling qemu-img convert  https://review.opendev.org/c/openstack/cinder/+/964541
14:47:20 <erlon> you're talking about reporting the flexvol capacity right? The capacity is completely different from the provisioned size. You can have a 1TB flexvol, with 10 1TB thin volumes, so the safest approach is usually to loop over the created volumes in the storage and return the sum
14:48:06 <Anoop_Shukla> Doesnt that make provisioned_capacity_gb = allocated_capacity_gb?
14:49:40 <Anoop_Shukla> Also, if my provisioned capacity in actuals for a flexvol is not going to be just the aggregated luns, Cinder continues to report wrong provisioned_capacity_gb? Scheduling can fail on a FlexVol which has a thick LUN created outside Cinder..but Cinder only reports Cinder Volumes?
14:50:03 <rosmaita> So, in the code there are some notes that differ from that queens spec:
14:50:03 <rosmaita> https://opendev.org/openstack/cinder/src/branch/master/cinder/volume/driver.py#L852-L856
14:50:03 <rosmaita> https://opendev.org/openstack/cinder/src/branch/master/cinder/interface/volume_driver.py#L128-L131
14:50:14 <erlon> They are fairly similar, and equal most of the time. The only difference is that the allocated_capacity_gb does not account for volumes not created by Cinder. This is a situation that is not common, since most cloud configuration creates one pool dedicated for Cinder. So, for practical reasons, you can consider them the same.
14:51:30 <Anoop_Shukla> @Ro
14:52:03 <erlon> Not sure what you mean with your last question
14:52:05 <Anoop_Shukla> https://www.irccloud.com/pastebin/Yr2ykUA7
14:53:05 <Anoop_Shukla> As per the code it means it needs to report pool’s provisioned space irrespective of who does the provisioning.
14:53:56 <erlon> yes
14:55:04 <Anoop_Shukla> Since the snapshots created do not account to provisioned_space at FlexVol, I think reporting the FlexVol’s provisioned_space would be more accurate.
14:55:06 <jbernard> Anoop_Shukla, jayaanand: you're welcome to just write it here, it keeps the log intact
14:56:07 <Anoop_Shukla> The implementation also does not consider LUNs space allocation..
14:58:16 <erlon> Anoop_Shukla: why don't you make a test? Run both methods (sum of luns, thin+thick vs FlexVol’s provisioned_space) in a test flexvol, with snapshots and luns, then see if FlexVol’s provisioned_space is accurate?
14:58:44 <Anoop_Shukla> As per the code comment: The total provisioned capacity on the storage backend, in gigabytes (GiB), including space consumed by any user other than Cinder itself.
15:00:23 <Anoop_Shukla> erlon: We have done this evaluation. The patch: https://review.opendev.org/c/openstack/cinder/+/968831 addresses this. We did this testing and found the flexvol approach was the most accurate.
15:00:55 <Anoop_Shukla> Right now the implementation is flag based. But we wanted to make this actual change for without flag/config being added to cinder.conf
15:04:07 <jbernard> we're at time, last call
15:04:49 <jbernard> #endmeeting