15:02:44 <enriquetaso> #startmeeting cinder_bs
15:02:44 <opendevmeet> Meeting started Wed Jan 11 15:02:44 2023 UTC and is due to finish in 60 minutes.  The chair is enriquetaso. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:44 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:44 <opendevmeet> The meeting name has been set to 'cinder_bs'
15:03:14 <enriquetaso> Hello, only one bug for today's meeting and it's already assigned
15:03:32 <enriquetaso> # svf : if pool attribute is specified in volume type during retype along with --migration-policy defaults to cinder generic migration
15:03:40 <enriquetaso> #topic svf : if pool attribute is specified in volume type during retype along with --migration-policy defaults to cinder generic migration
15:03:58 <enriquetaso> #link https://bugs.launchpad.net/cinder/+bug/2001619
15:04:27 <enriquetaso> svf driver needs to implement retype with migrations on their driver
15:04:58 <Sathya> yes
15:05:39 <Sathya> we are trying to implement non disruptive migration
15:06:19 <happystacker> I have opened a new bug today, do I need to add it somewhere?
15:06:27 <enriquetaso> thanks Sathya, i think there's not fix proposed upstream yet
15:06:36 <Sathya> when the pool parameter is mentioned in the volume type it's entering cinder generic migration instead of driver specific implementation
15:07:22 <enriquetaso> happystacker, sure, let's mentioned it on the open discussion, I'll add it on the next week email report
15:07:40 <happystacker> excellent! thank you
15:08:36 <enriquetaso> Sathya++ anything else to share?
15:09:35 <Sathya> i had discussion with rajat , he said we could take this up as pool attribute is concerned for most of storage drivers
15:10:33 <Sathya> whoami-rajat you there?
15:11:26 <Sathya> Our customer requirement needs the pool also for the migration
15:11:43 <enriquetaso> i think he's in a meeting
15:12:02 <enriquetaso> ohh, so it may involve some code change on the manager.py
15:12:15 <Sathya> is there any concerns if we could add this pool attribute in the manager.py
15:13:33 <enriquetaso> well.. If the change is justified I don't see the problem.. if you proposed a patch for the mid cycle we can discuss it there and get cinder team attention
15:16:04 <enriquetaso> okay, any other comments?
15:16:06 <Sathya> we will try to make the changes and test, and to raise the patch
15:16:16 <enriquetaso> thanks Sathya !
15:16:20 <eharney> i think i fixed our py311 failures we discussed last week, just waiting for CI issues to shake out
15:16:29 <enriquetaso> \o/
15:16:30 <enriquetaso> yay
15:16:35 <enriquetaso> eharney++
15:16:42 <enriquetaso> okay, moving to open discussion
15:16:52 <enriquetaso> #topic open discussion
15:17:05 <enriquetaso> happystacker, do you mind sharing the bug link?
15:17:07 <happystacker> I have opened this bug
15:17:08 <happystacker> https://bugs.launchpad.net/cinder/+bug/2002535
15:17:21 <sfv880_> Hello reviewers, I addressed all the comments on https://review.opendev.org/c/openstack/cinder/+/852369 and https://review.opendev.org/c/openstack/cinder/+/864287 - it is very important for us and our customers are waiting for these fixes to be merged. Also, these changes are required to pass the RHOSP certification. Could you please help me and review it ? Thank you so much!
15:17:32 <happystacker> this occurs when resizing a server
15:17:42 <happystacker> it's an NFS env
15:17:59 <happystacker> it seems that qemu-img is converting a qcow2 to raw
15:18:02 <eharney> is this related to the NFS bug we were already working on re: qcow2/raw format handling?
15:18:09 <eharney> enriquetaso: ^
15:18:21 <happystacker> it sounds similar
15:18:33 <happystacker> that happens with image volume caching enabled
15:18:53 <happystacker> don't understand why this conversion of raw happens
15:19:20 <enriquetaso> i think it's not, but i need to look at it a big more
15:19:23 <happystacker> and the attachment doesn't get updated, so attachment is waiting for qcow2 and file is raw
15:19:41 <enriquetaso> good one: i need to try my patch with cache enabled
15:19:50 <happystacker> if we manually convert it back to qcow2, then resize work
15:20:06 <eharney> it would be good if the bug described what cinder operations happen when that nova resize occurs
15:20:09 <enriquetaso> that's strange
15:20:23 <happystacker> if I disable cache, it works fine
15:21:01 <eharney> sounds worth digging into, for sure
15:21:03 <happystacker> I can update and add more information
15:21:25 <happystacker> and do a comparaison nova/cinder at the time of the failure
15:22:35 <enriquetaso> that sounds good, would be nice to have the cinder operations
15:22:38 <enriquetaso> happystacker++
15:23:11 <enriquetaso> just wondering: do you have a patch for this bug happystacker or you just faced it ?
15:25:54 <opendevreview> Eric Harney proposed openstack/cinder master: Tests: storwize: Work around bug in unit test  https://review.opendev.org/c/openstack/cinder/+/869853
15:25:57 <roquej> no patch yet
15:25:59 <enriquetaso> looks like happystacker is gone lol
15:26:05 <roquej> i'm back lol
15:26:16 <enriquetaso> oh cool
15:26:20 <roquej> i'd like to understand the reason of that concersion
15:26:23 <roquej> conversion
15:26:30 <roquej> qcow2 to raw
15:27:36 <enriquetaso> sounds good, the generic nfs do some raw conversion when getting the image from glance and then converts to qcow2 but that shouldnt be affecting this
15:27:48 <enriquetaso> okay, only 3 minutes left
15:28:01 <enriquetaso> any other bug to discuss?
15:28:03 <eharney> i just submitted this patch above to close out a six year old bug ^
15:28:13 <enriquetaso> sfv880_, i'll add the patches to my review list
15:28:19 <roquej> It seems that this conversion happens from qcow2 to raw
15:28:28 <roquej> but never got back to qcow2
15:28:36 <roquej> which is an issue
15:28:51 <roquej> I'll move on digging it
15:29:07 <enriquetaso> thanks eharney
15:29:40 <roquej> I have to drop. Thank you guys
15:29:45 <enriquetaso> thanks!
15:30:37 <enriquetaso> Argonauts please review patches
15:30:43 <enriquetaso> thanks
15:30:46 <enriquetaso> #endmeeting