14:02:42 <jbernard> #startmeeting cinder
14:02:42 <opendevmeet> Meeting started Wed Mar  8 14:02:42 2023 UTC and is due to finish in 60 minutes.  The chair is jbernard. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:42 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:42 <opendevmeet> The meeting name has been set to 'cinder'
14:02:48 <happystacker> hello
14:02:52 <eharney> hi
14:02:57 <jbernard> #roll call
14:03:05 <jbernard> #topic roll call
14:03:14 <Mounika> Hi
14:03:20 <mubeen> Hi
14:03:21 <jungleboyj> o/
14:03:29 <Sathya> hi
14:03:33 <zaitcev> o/
14:03:47 <jbernard> hello everyone o/ , rajat is out at this time so I'm going to try to work the meetbot for today's meeting
14:04:03 <felipe_rodrigues> o/
14:04:15 <HelenaDantas[m]> o/
14:04:17 <happystacker> o/
14:04:40 <thiagoalvoravel> o/
14:04:45 <MatheusAndrade[m]> o/
14:04:59 <caiquemello[m]> o/
14:05:04 <tobias-urdin> o/
14:05:14 <lucasmoliveira059> \o
14:06:07 <jbernard> ok, let's get started
14:06:15 <jbernard> #topic annoucements
14:06:24 <jbernard> Cinder RC1 has been released!
14:06:51 <jbernard> the stable/2023.1 branch has been cut and master is now the 2023.2 (Bobcat) development branch
14:07:17 <jbernard> There will be an RC-2, so continue to prioritize reviews on this etherpad:
14:07:28 <jbernard> #link https://etherpad.opendev.org/p/cinder-antelope-fixes-rc
14:07:52 <jbernard> patch authors: make sure the notes about your patch on ^^ are up to date on an ongoing basis, it affects whether someone reviews or waits for an update
14:08:16 <jungleboyj> \o/
14:08:35 <jbernard> all patches must merge to master FIRST and then be BACKPORTED to stable/2023.1
14:08:42 <jbernard> patch authors: ^^  pay attention an propose the backport as soon as your patch has merged (do NOT propose earlier)
14:09:32 <jbernard> for 2023.2 (Bobcat) release planning,
14:09:38 <jbernard> We will conduct Cinder virtual PTG from 28th March (Tuesday) to 31st March (Friday), 2023
14:09:45 <jbernard> Timings will be 1300-1700 UTC -- This time slot has worked for us in the past several PTGs so keeping it same
14:09:52 <jbernard> Please add your topics to the planning etherpad
14:10:03 <jbernard> #link https://etherpad.opendev.org/p/bobcat-ptg-cinder-planning
14:10:46 <rosmaita> o/
14:10:59 <jbernard> #topic Cinder retype for migration , passing the new volume type id to the drivers
14:11:15 <jbernard> #link https://bugs.launchpad.net/cinder/+bug/2001619
14:11:23 <jbernard> ^ links to the previously raised bug
14:11:31 <Sathya> Hi
14:11:43 <Sathya> Eralier we had this discussion with geguileo, on cinder retype for migration, where volume type with additional extra specs
14:11:43 <Sathya> should have a chance to enter driver specific code
14:12:06 <Sathya> Now i have observed that the new volume type is not being sent to the driver thorugh
14:12:06 <Sathya> driver.migrate_volume(ctxt,volume,host)
14:12:20 <Sathya> where as new volume type id value is being passed to cinder generic migration
14:12:20 <Sathya> self._migrate_volume_generic(ctxt, volume, host, new_type_id)
14:12:31 <Sathya> I believe this is a important parameter to be passed, but since it's migrate_volume function defnition
14:12:32 <Sathya> inclusion of this parameter might pose some issues to other drivers
14:13:41 <geguileo> Sathya: I don't remember what I said in the conversation, but I vaguely remember drivers not needing that...
14:14:22 <Sathya> calling to check driver whether it could handle extra specs
14:15:28 <Sathya> https://review.opendev.org/c/openstack/cinder/+/869999
14:16:28 <Sathya> this is the gerrit link for our initial discussion
14:20:01 <jbernard> Sathya: I think we can discuss this further in #openstack-cinder after the meeting
14:20:13 <Sathya> sure
14:20:46 <jbernard> do you need anything in addition to further design discussion, like a request for review, what would help most?
14:21:23 <geguileo> just one last question
14:21:40 <geguileo> Sathya: Why wasn't the migration implemented on the "retype" method of your driver?
14:22:51 <Sathya> our backend has now come up with this new non disruptive migration
14:23:38 <geguileo> why can't you do the migration on the retype?
14:23:53 <geguileo> you driver is called on a retype when just the backend has changed
14:25:18 <geguileo> Sathya: maybe the call to know if the driver can do the retype needs to be in the manager's retype instead of the migrate
14:25:44 <Sathya> we had those additional extra specs, which was not entering driver code, that's why bug was raised
14:26:09 <geguileo> Sathya: but you were focusing on the migrate part of the code
14:26:20 <geguileo> and apparently I didn't think of this as a whole
14:26:50 <geguileo> because it makes more sense that it's the "retype" method in the manager the one that checks with the driver if it can do the retype
14:27:23 <Sathya> yes it's regarding cinder retype for migration
14:27:58 <geguileo> so I think the fix should be in the manager's retype
14:28:09 <Sathya> yes
14:28:27 <geguileo> please have a look at that code and how this same idea of having the driver tell whether it can do it efficiently can be applied there
14:30:37 <Sathya> i tried several approach , it's not suiting , can we have this discussion separately
14:31:23 <geguileo> Sathya: I don't have time these days, so it's going to be hard for me to assist you on this one
14:33:19 <Sathya> any further discussions is it possible in video call meetings
14:34:46 <rosmaita> Sathya: put it on the agenda for the virtual PTG
14:34:57 <Sathya> sure
14:34:59 <jbernard> we do have our PTG meeting in video from March 28 to March 31, so that might be an option
14:35:10 <Sathya> ok
14:35:15 <rosmaita> #link https://etherpad.opendev.org/p/bobcat-ptg-cinder-planning
14:36:09 <jbernard> thanks Sathya
14:36:24 <jbernard> #topic review requests
14:36:57 <jbernard> there are 2 for Dell PowerMax by happystacker
14:37:04 <jbernard> #link https://review.opendev.org/c/openstack/cinder/+/797970
14:37:08 <jbernard> and
14:37:10 <jbernard> #link https://review.opendev.org/c/openstack/cinder/+/858370
14:38:00 <jbernard> Fujitsu Eternus by inori
14:38:05 <jbernard> #link https://review.opendev.org/c/openstack/cinder/+/847730 (feature add)
14:38:55 <jbernard> ^ this one has a -1 from whoami-rajat to wait until stable/2023.1 is cut, but that has just happened
14:39:07 <jbernard> and
14:39:09 <jbernard> Increase size of volume image metadata values (drencrom)
14:39:12 <jbernard> #link https://review.opendev.org/c/openstack/cinder/+/868485 (need one more +2)
14:39:47 <jbernard> #topic open discussion
14:41:25 <zaitcev> I'm also back with https://review.opendev.org/c/openstack/cinder/+/852654, with which you helped once, and whoami-rajat had to circle back because I'm dumb and missed one of his important comments. I want to hear two things: 1. is there a better name than volume_is_fresh and 2. is the new test okay.
14:43:37 <zaitcev> Rajat pointed out that "fresh" is essentially synonymous with "new", and both means "freshly created". But I want to convey something else: that the volume is safe for a sparse restore, because it has no old data.
14:44:11 <zaitcev> I'm almost desperate enough to name it "volume_sparse_ok".
14:44:11 <rosmaita> how about volume_is_safe_for_sparse_restore   ?
14:44:22 <happystacker> lol
14:44:56 <rosmaita> i'm serious, either that or a comment in the rpc/api.py restore() that explains what "fresh" means for that parameter
14:44:59 <zaitcev> I like the meaning of it but it's inconveniently long.
14:45:26 <rosmaita> well, that's what the \ is for!
14:46:46 <rosmaita> either that or "volume_has_data" as a bool (though that would flip the logic)
14:47:31 <zaitcev> Allright.
14:48:31 <zaitcev> As for the test, I wanted to copy what volume service does with ddt, which looks elegant, but only works because the service has its own _get_cctxt.
14:52:32 <jbernard> ok, this is specifically for test_rpcapi.py, i will need to look at this more closely as im not immediately sure
14:53:06 <jbernard> #link https://review.opendev.org/c/openstack/cinder/+/852654
14:53:29 <jbernard> ^ this is an additional review request in case anyone is looking for more
14:55:51 <jbernard> ok, unless there is antyhing else I think we can wrap up
14:57:12 <jbernard> thanks everyone!
14:57:18 <jbernard> #endmeeting