15:02:26 <enriquetaso> #startmeeting cinder_bs
15:02:26 <opendevmeet> Meeting started Wed Sep  7 15:02:26 2022 UTC and is due to finish in 60 minutes.  The chair is enriquetaso. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:26 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:26 <opendevmeet> The meeting name has been set to 'cinder_bs'
15:02:38 <whoami-rajat> Hi
15:02:40 <enriquetaso> Hello, welcome to the bug meeting
15:03:04 <enriquetaso> we have 2 bugs for today's meeting and two old bugs
15:03:23 <rosmaita> o/
15:03:35 <enriquetaso> #link https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030380.html
15:03:48 <enriquetaso> #topic With image-volume cache enabled backend, volume creation for a smaller volume than image-volume cache has the same size as the image-volume cache.
15:03:53 <enriquetaso> #link https://bugs.launchpad.net/cinder/+bug/1988803
15:03:57 <enriquetaso> Long title.
15:04:04 <enriquetaso> This issue has a kind of long history on the Bugzilla link included in the launchpad report for those interested in the case.
15:04:10 <enriquetaso> Summary: Cinder creates a volume whose requested size is smaller than the image cache volume and has the same size as the image cache volume. That results in an inconsistency between Cinder and the storage backend.
15:04:30 <enriquetaso> The reporter forgot to mention the backend but I think it's reproducible throw the backends.
15:05:03 <enriquetaso> The reporter suggests a possible solutions: https://bugs.launchpad.net/cinder/+bug/1988803/comments/1
15:05:41 <enriquetaso> Quoting abishop: Any design changes like that would require writing a spec and more.
15:05:41 <enriquetaso> Should we treat this like a bug or as a feature improvement?
15:05:54 <whoami-rajat> I was thinking at looking at it at some point
15:06:03 <whoami-rajat> s/at/of
15:06:23 <whoami-rajat> this looks doable
15:06:32 <rosmaita> seems like a bug if cinder says the volume is 1GB but it is really 5GB
15:07:04 <abishop> yes, that aspect is definitely a bug
15:07:06 <whoami-rajat> i think the second one is the way to go, just create the volume as big as required by the image
15:07:06 <eharney> i agree, it's a bug
15:07:28 <abishop> some of the discussions that proposed changes got complicated
15:08:14 <enriquetaso> yes, i got confused from the discussion
15:08:39 <anskiy> I've filed this change, that addresses similiar issue, but I've found, that it doesn't resize create volume _file_ to the volume size at all: https://review.opendev.org/c/openstack/cinder/+/855964
15:10:02 <yuval__> I did saw the patch and was not sure why its needed
15:10:24 <yuval__> I see it was trying to workaround this bug...
15:11:30 <whoami-rajat> left a comment on the patch, looks like it won't work if the new volume has size < original volume since we don't support shrinking a volume, resize=extend
15:12:34 <abishop> some proposed (in email discussions) changes felt rather "opionated" to me (i.e. behavior that not all operators would want), which is why I felt it was time for a spec
15:12:45 <anskiy> yuval__: I saw your comment, just didn't have time to respond properly, sorry. No, I wasn't trying to workaround it, I've found this problem the other way around: small image, big volume and on NFS (haven't seen such problems with LVM driver, and not sure about the others, so fix is for NFS only)
15:13:10 <rosmaita> i was just going to ask, is there any reason to think this is NFS-specific?
15:13:47 <whoami-rajat> I think it's generic to all drivers, as our image cache feature is
15:13:58 <rosmaita> that's my thought too
15:14:02 <eharney> seems like it would be for any driver
15:14:11 <anskiy> it's broken in the point, where new volume create from snapshot of other volume -- the snapshot size is set to the original volume size
15:14:30 <anskiy> in qemu-img command, that is.
15:14:37 <opendevreview> Vladislav Belogrudov proposed openstack/cinder master: Tatlin driver: add more tests and improve code  https://review.opendev.org/c/openstack/cinder/+/853315
15:15:28 <rosmaita> anskiy: i see, the snapshot could be really big, but is going to be set to whatever cinder thinks the original volume size is, which could be pretty small
15:16:45 <anskiy> yes, and with LVM driver it is not triggered, because it creates snapshot via lv* things. I'm totally unsure about drivers besides these ones, sorry
15:17:19 <anskiy> so that's why I've sent this change specifically for NFS driver
15:17:49 <rosmaita> ok
15:18:35 <enriquetaso> Makes sense. However, looks like we should probably go for a generic / driver-independent approach if possible.
15:19:30 <rosmaita> agreed
15:20:09 <enriquetaso> Not sure to understand the snapshot case correctly... Should we create a new bug report for the snapshot case + nfs driver?
15:22:30 <enriquetaso> anskiy, would you mind creating a launchpad report describing the snapshot size issue you mentioned. It would be nice to link it to https://review.opendev.org/c/openstack/cinder/+/855964 too
15:23:10 <rosmaita> my impression is: create a 10GB volume A from an image with image-cache enabled, then create a 1 GB volume B from the same image, then use volume B and add 2GB of data to it, then snapshot volume B, create volume C from the snapshot, volume C gets resized to 1 GB
15:23:33 <rosmaita> and the "extra" data goes missing
15:23:43 <rosmaita> anskiy: is that roughly correct?
15:25:39 <anskiy> rosmaita: nah, it's easier :) create 10G volume A from image with image-cache, then it's _real_ size on filesystem (qemu-img info, ls...) would be the size of cache volume.
15:27:22 <anskiy> it just gets created via qemu-img snapshot mechanically
15:28:49 <eharney> sounds worth investigating
15:28:58 <rosmaita> ok, hopefully i misunderstood and there's not a data loss issue here
15:29:19 <anskiy> enriquetaso: sure, I hope to find some time to do it this week
15:30:29 <rosmaita> anskiy: sounds like what you are describing is the same as https://bugs.launchpad.net/cinder/+bug/1988803 , just for NFS
15:34:24 <anskiy> rosmaita: yeah, looks similar, and I can't see with which driver this bug happens, as I've said earlier, it's fine with LVM...
15:39:42 <enriquetaso> OK, looks like worth investigating so please anskiy fill a bug on cinder launchpad please :D
15:39:46 <enriquetaso> moving on
15:40:05 <enriquetaso> #topic Remove IET iSCSI target
15:40:12 <enriquetaso> #link https://bugs.launchpad.net/cinder/+bug/1988317
15:40:24 <enriquetaso> As we discussed in our last meeting I've created a bug report to remember us that we need to deprecate IET ISCSI target. Looks like a low-hanging-fruit to me.
15:40:55 <eharney> it's already deprecated -- we need to remove it :)
15:41:42 <enriquetaso> oh sorry about that
15:42:07 <rosmaita> yes, the deprecation period is over, and we forgot to remove it
15:42:17 <enriquetaso> any volunteer to do it? :) Maybe I can work with an inter with this
15:42:19 <rosmaita> so we can remove it whenever we want to
15:42:31 <rosmaita> i think it might be a good intern bug
15:42:50 <rosmaita> not critical, but needs to get done
15:43:29 <enriquetaso> sounds good then :)
15:44:05 <enriquetaso> OK so the old and last bug for today's meeting is:
15:44:10 <enriquetaso> #topic Out of space when migrating encrypted volume between two LVM backends
15:44:17 <enriquetaso> #link https://bugs.launchpad.net/cinder/+bug/1720885
15:44:22 <enriquetaso> It would be nice to check if this is still a problem present in the LVM backend. Looks like a problem, we would like to fix this since it's kind of a basic functionality between encrypted volumes.
15:44:43 <enriquetaso> Do you have any thoughts? It would be nice if a great person offer to confirm this and/or work on this
15:44:56 <enriquetaso> Since we don't have updates on this bug in a long time.
15:45:02 <enriquetaso> If nobody would like to confirm I'll try to do it by the end of this week.
15:45:25 <eharney> isn't this the encryption header size issues?
15:48:48 <enriquetaso> I think the header size issues involves mostly volumes that are not encrypted when migrating them to encrypted types. The original volume lacks of space and the operation fails.
15:49:17 <enriquetaso> I think this may be related of not :/ I'm not sure
15:52:47 <opendevreview> Felipe Rodrigues proposed openstack/cinder master: NetApp NFS: Clone image using copy file operation  https://review.opendev.org/c/openstack/cinder/+/847732
15:59:22 <enriquetaso> OK, we are running out of time
16:01:24 <enriquetaso> thank you for attending
16:01:34 <enriquetaso> #endmeeting