14:01:11 <whoami-rajat_> #startmeeting cinder
14:01:11 <opendevmeet> Meeting started Wed Jul 17 14:01:11 2024 UTC and is due to finish in 60 minutes.  The chair is whoami-rajat_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:11 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:11 <opendevmeet> The meeting name has been set to 'cinder'
14:01:17 <whoami-rajat_> #topic roll call
14:01:24 <Sai> o/
14:01:57 <rosmaita> o/
14:01:58 <whoami-rajat_> Jon has some conflicts so I will be chairing today's meeting
14:02:02 <eharney> hi
14:02:21 <kpdev> hi
14:02:42 <msaravan> hi
14:03:18 <whoami-rajat_> #link https://etherpad.opendev.org/p/cinder-dalmatian-meetings
14:03:39 <jungleboyj> o/
14:04:47 <tosky> hi
14:04:51 <ccokeke[m]> hello
14:05:16 <akawai> o/
14:05:20 <whoami-rajat_> hello everyone
14:05:32 <whoami-rajat_> let's get started
14:05:45 <whoami-rajat_> I haven't prepared much for the announcements
14:05:51 <whoami-rajat_> just few upcoming deadlines
14:05:58 <whoami-rajat_> 1. New feature status checkpoint (R-9, Aug-02)
14:06:04 <whoami-rajat_> #link https://releases.openstack.org/dalmatian/schedule.html#d-cinder-feature-checkpoint
14:06:27 <whoami-rajat_> if you are planning to implement a feature, this is a reminder to start preparing for it
14:06:54 <yuval> o/
14:07:20 <whoami-rajat_> a highlight of this would be to keep in mind the client release is earlier (M3) than the final project release
14:07:53 <whoami-rajat_> so it's better to keep your feature ready beforehand so reviewers have plenty time to test the client + feature changes
14:08:17 <whoami-rajat_> 2. Midcycle-2 (R-7 Aug-14)
14:08:21 <whoami-rajat_> #link https://releases.openstack.org/dalmatian/schedule.html#d-cinder-mid-cycle-ptg-2
14:08:43 <whoami-rajat_> we will be conducting another session of midcycle before the feature freeze to ensure everything is on track
14:09:36 <whoami-rajat_> 3. M3 (R-5, Aug-30)
14:09:42 <whoami-rajat_> #link https://releases.openstack.org/dalmatian/schedule.html#d-3
14:10:27 <whoami-rajat_> this has a bunch of deadlines like feature freeze, client library release, requirement freeze and a few more things
14:12:19 <yuval> "implement a feature" - this is also vendor feature? or pure cinder features?
14:12:24 <whoami-rajat_> other than that i couldn't find anything interesting related to our project
14:12:30 <whoami-rajat_> yuval, both
14:12:45 <yuval> I have a patch up - not sure if it counts as a feature
14:13:15 <yuval> its enabling a behavior for our driver
14:13:29 <yuval> thats a "feature"?
14:13:36 <whoami-rajat_> do you have a link?
14:14:10 <yuval> https://review.opendev.org/c/openstack/cinder/+/924323
14:15:31 <whoami-rajat_> looks like a feature to me
14:16:28 <yuval> I see but it does not need any client support
14:16:55 <yuval> anyway I would like it to be merge before aug 26
14:17:20 <yuval> sorry for interrupt please continue
14:18:17 <whoami-rajat_> yes it doesn't, i was just stating that for awareness if anyone has a feature that requires client support, it's better to get that support added on time
14:18:22 <whoami-rajat_> it doesn't apply to your case
14:18:47 <whoami-rajat_> I'm done with announcements, anyone has anything else to announce
14:22:28 <whoami-rajat_> ok looks like not
14:22:33 <whoami-rajat_> let's proceed with topics
14:22:46 <whoami-rajat_> #topic reminder: vendors (particularly quobyte, virtuozzo, and nfs-based drivers) should verify that the recent CVE-2024-32498 fix has not caused a regression
14:22:48 <whoami-rajat_> rosmaita, that's you
14:22:56 <rosmaita> thanks
14:23:03 <rosmaita> the topic pretty much says it all
14:23:24 <whoami-rajat_> i think netapp reported a scenario where it caused a regression
14:23:33 <rosmaita> #link https://review.opendev.org/c/openstack/cinder/+/923244
14:23:40 <rosmaita> oh, i did not see that yet
14:23:47 <msaravan> https://bugs.launchpad.net/cinder/+bug/2073146
14:24:17 <msaravan> this is the bug we logged..and hitting this issue when glance backend is based on Cinder NFS
14:24:21 <whoami-rajat_> i was looking into it and it might need to leverage the format information we store in admin metadata
14:24:29 <whoami-rajat_> but i didn't have an nfs env to confirm or work on it
14:24:38 <whoami-rajat_> but looks like a real issue
14:25:30 <msaravan> whoami-rajat_: I can share my environment, if you want to get into a call to see this
14:26:09 <yuval> "real size is 1" maybe thats in GB and the qcow side is in kb?
14:26:11 <rosmaita> msaravan: i may take you up on that
14:26:28 <msaravan> rosmaita:  Sure, we can work on that.
14:26:30 <rosmaita> yuval: yes, looks like there's a unit mismatch
14:27:20 <rosmaita> msaravan: let's talk after this meeting and set something up
14:27:41 <msaravan> rosmaita: sure
14:28:45 <rosmaita> ok, that's all from me
14:29:01 <whoami-rajat_> thanks rosmaita
14:29:11 <whoami-rajat_> #topic Storpool clone-across-pools
14:29:15 <whoami-rajat_> rosmaita, that's you again
14:29:17 <kpdev> For storpool, i saw recent comment from Brian. @rosmaita, are you suggesting you ok with this feature but it does not need entry in support matrix ? regarding documentation, yes we can add that via separate PR under this blue-print
14:29:51 <rosmaita> yeah, i just wanted to give a pointer to the discussion of this Storpool feature
14:30:16 <rosmaita> (because i had completely forgotten it)
14:30:22 <whoami-rajat_> but i think it's not storpool specific, other driver vendors could also leverage it who support cross pool cloning?
14:30:31 <rosmaita> yes, exactly
14:30:34 <kpdev> +1
14:30:38 <rosmaita> #link https://www.youtube.com/watch?v=yvRVS9aic5o
14:30:49 <rosmaita> discussion starts at 2:18 and ends at 27:49
14:30:49 <whoami-rajat_> yeah we should move that forward
14:31:04 <yuval> simon here?
14:31:07 <whoami-rajat_> I was also planning to have similar support in case when cinder is glance backend
14:31:21 <rosmaita> kpdev: yes, i think as a team we are fine with the feature, but maybe this does not need to go into the support matrix
14:31:50 <kpdev> ok, i will remove support matrix entry
14:32:11 <jungleboyj> rosmaita:  We would only have a couple of drivers implement this?
14:32:17 <rosmaita> kpdev: you can mention it prominently in the storpool driver docs
14:32:28 <kpdev> yes. sure will add documentation
14:32:38 <rosmaita> jungleboyj: don't know ... storpool at first, maybe some others
14:33:02 <rosmaita> i think we've had massive turnover in driver maintainers since may 2022
14:33:05 <jungleboyj> Ok.  Then I don't think we need to add it to the matrix.  Can re-address if more drivers start adding it.
14:33:24 <kpdev> ack
14:33:26 <rosmaita> so that's why i wanted to flag the video, so maybe other drivers that can do this too will know about it
14:33:44 <jungleboyj> The matrix would was intended to show features that consumers would be expecting.
14:34:07 <jungleboyj> kpdev: I think it makes sense for you to highlight it in your documentation.
14:34:46 <kpdev> yes, sure will add in doc after this gets added.
14:35:36 <yuval> regarding the bug: this is probably the offending line:  if info.virtual_size != volume.size * units.Gi:
14:35:59 <yuval> in the nfs driver
14:37:38 <whoami-rajat_> rosmaita, thanks for bringing this up, i think we are good on this topic then?
14:37:50 <rosmaita> yeah, that's all from me
14:37:55 <whoami-rajat_> thanks
14:38:05 <whoami-rajat_> we don't have any more topics for today
14:38:20 <whoami-rajat_> we have a bunch of review requests from different driver vendors
14:38:28 <whoami-rajat_> so please take a look at them
14:38:36 <whoami-rajat_> let's move to open discussion
14:38:39 <whoami-rajat_> #topic open discussion
14:39:04 <yuval> I had an issue today
14:39:43 <yuval> In one of my patches there was a request to add the "Depends-on" (that was a good comment) but when I change the commit message gerrit created a new patch
14:39:56 <yuval> how should I continue with that close the old one?
14:40:18 <yuval> or I can somehow force my changes on the same patch
14:40:35 <yuval> this is the old one:https://review.opendev.org/c/openstack/cinder/+/903573 new one: https://review.opendev.org/c/openstack/cinder/+/924323
14:41:18 <eharney> you should be able to edit the Depends-On into the old patch, just make sure the Change-Id is in the footer of the commit message and not moved
14:41:49 <yuval> this what caused the change: I added "os_brick patch: https://review.opendev.org/c/openstack/os-brick/+/903574"
14:41:55 <yuval> (not the Depends-on)
14:42:41 <whoami-rajat_> did you do ``git commit`` instead of ``git commit --amend`` ?
14:43:00 <eharney> the new patch has two Change-Ids, probably added an empty line at the end or so
14:43:11 <yuval> no, it was added to the commit
14:43:18 <yuval> the commit msg
14:44:04 <yuval> maybe I should put the "os-brick" line before the new line?
14:45:14 <rosmaita> well, if you have the change-id by itself as the very last thing in the commit message, the commit-msg hook should see it and not add a new one
14:45:18 <rosmaita> (in theory)
14:46:33 <yuval> ah I see a new change-ID was added
14:46:56 <rosmaita> yeah, and tbh, i am not sure why that happened
14:47:30 <yuval> ok, never mind - I dont want to add any more patches
14:47:53 <yuval> I am leaving the new and closing the rest
14:50:00 <yuval> I would really appreciate someone going over these patches, they are tested and ready
14:52:42 <rosmaita> ok, just abandon the ones that we don't need to look at
14:53:21 <yuval> yes just done that, thanks
14:54:25 <yuval> regarding the nfs bug - I dont think there is a need to bring up the whole system, but through the unittest - test_initialize_connection - it could be tested
14:54:41 <yuval> there is a negative unittest test_initialize_connection_raise_on_wrong_size
15:00:18 <whoami-rajat_> yuval, i think the problem is before that logic, we are trying to do a qemu-img info on a qcow2 volume that is actually a raw volume
15:00:31 <whoami-rajat_> i don't have all the details but it will need a real configuration with glance using cinder
15:00:38 <whoami-rajat_> we are out of time
15:00:44 <whoami-rajat_> thanks everyone for joining
15:00:46 <whoami-rajat_> #endmeeting