14:00:22 <rosmaita> #startmeeting cinder
14:00:22 <opendevmeet> Meeting started Wed Sep 15 14:00:22 2021 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:22 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <opendevmeet> The meeting name has been set to 'cinder'
14:00:27 <rosmaita> #topic roll call
14:00:29 <simondodsley> o/
14:00:50 <whoami-rajat> Hi
14:00:52 <manoj_katari> Hi
14:01:27 <geguileo> hi! o/
14:01:28 <walshh_> Hi
14:01:35 <TusharTgite> hi
14:01:36 <eharney> hi
14:01:41 <sfernand> hi
14:01:54 <enriquetaso> hi
14:02:14 <fabiooliveira> hi
14:02:41 <jungleboyj> o/
14:02:51 <rosmaita> hello everyone
14:02:56 <rosmaita> good turnout!
14:03:02 <rosmaita> #topic announcements
14:03:20 <rosmaita> RC-1 must be released tomorrow
14:03:30 <rosmaita> and the stable/xena branch will be cut
14:03:55 <rosmaita> after that point, any xena bugs must be proposed to master and then backported to stable/xena
14:04:16 <rosmaita> obviously, that will take extra time, so be aware of that
14:04:44 <rosmaita> only absolutely release-critical bugs will be allowed into stable/xena after tomorrow
14:05:03 <rosmaita> so, obviously, any of those will have review priority
14:05:39 <rosmaita> we already have one of which i am aware, but we can get it into RC-1 because it already has a +2
14:05:49 <rosmaita> #link https://review.opendev.org/c/openstack/cinder/+/807083
14:06:16 <rosmaita> would be good to have it in RC-1 so it doesn't prevent anyone from testing with the release candidate
14:06:35 <rosmaita> it has been validated independently by an operator who ran into it
14:06:57 <rosmaita> ok, let's review where we stand with Xena features
14:07:08 <rosmaita> #link https://etherpad.opendev.org/p/cinder-xena-ffe
14:07:09 <whoami-rajat> also verified by the kolla team in their gate with centos and ubuntu jobs
14:07:23 <rosmaita> excellent!
14:07:52 <rosmaita> ok, first thing to notice on https://etherpad.opendev.org/p/cinder-xena-ffe is that all the FFE requests have been merged
14:08:06 <rosmaita> so thanks to everyone who helped out the community and reviewed those
14:08:42 <rosmaita> we have a few outstanding patches for the secure rbac feature
14:08:51 <rosmaita> #link https://review.opendev.org/759961
14:08:59 <rosmaita> #link https://review.opendev.org/760153
14:09:44 <rosmaita> they are both in the zuul check now, had to be rebased, should be done by the time the meeting is over
14:10:13 <rosmaita> we also have two outstanding patches from the sqlalchemy-migrate --> alembic feature
14:10:29 <rosmaita> we need this one in RC-1:
14:10:38 <rosmaita> #link https://review.opendev.org/c/openstack/cinder/+/786933/
14:11:06 <rosmaita> there's a patch that depends on it, but it already has two +2s
14:11:24 <rosmaita> so i will +W it as soon as the prior patch merges
14:12:08 <rosmaita> ok, in order to make sure that everyone isn't standing around assuming that other people are reviewing, i would like some volunteers for the patches mentioned
14:12:56 <jungleboyj> I am looking at the Alembic.
14:13:03 <rosmaita> (at this point, people are supposed to say, "I will review patch ...")
14:13:06 <whoami-rajat> i can look at the alembic patch since I already reviewed most of the patches in chain
14:13:08 <rosmaita> jungleboyj: thank you
14:13:17 <eharney> i'm also looking at the alembic changes
14:13:31 <rosmaita> ok, so the db stuff is covered
14:13:51 <whoami-rajat> i will take a look at https://review.opendev.org/c/openstack/cinder/+/760153/ then
14:15:06 <rosmaita> thanks
14:15:24 <rosmaita> looks like https://review.opendev.org/c/openstack/cinder/+/759961/ already got +W
14:16:08 <rosmaita> oh, yeah, there will be a release note patch covering all the policy updates
14:16:17 <rosmaita> but i haven't finished writing it yet
14:16:36 <rosmaita> anyone want to volunteer to proofread it ?  i will ping you in irc
14:17:04 <jungleboyj> rosmaita:  Yeah, I will help with that one too.
14:17:16 <rosmaita> thanks jungleboyj
14:17:47 <rosmaita> ok, moving on
14:18:12 <rosmaita> i am happy to announce that our next Festival of XS Reviews is on Friday
14:18:30 <rosmaita> which is kind of a weird time to have it, but what the heck
14:19:07 <rosmaita> final item:
14:19:13 <jungleboyj> Awkward.. ;-)
14:19:16 <rosmaita> Yoga PTG in october
14:19:25 <rosmaita> #link https://etherpad.opendev.org/p/yoga-ptg-cinder-planning
14:19:29 <simondodsley> Eventbrite just opened the registration for the October PTG, so look out for the email and register...
14:19:33 <rosmaita> so, add topics, make sure you register, tec
14:19:39 <rosmaita> *etc
14:20:10 <sfernand> are we going to have a summit?
14:20:21 <rosmaita> i think the summit has moved to once a year
14:20:29 <rosmaita> but i forget when the last one was
14:20:41 <simondodsley> pre-Covid...
14:21:04 <rosmaita> simondodsley: right, but we did have a virtual kind of summit thingy at some point
14:21:12 <simondodsley> they don't count...
14:21:16 <rosmaita> :)
14:21:16 <jungleboyj> :-)
14:21:18 <whoami-rajat> it was last to last PTG i guess
14:21:26 <rosmaita> yeah, but on that topic ...
14:21:32 <jungleboyj> They were talking about doing something in Berlin this fall, but I don't see that happening.
14:21:45 <rosmaita> we've been using bluejeans to hold our PTG virtual meetings
14:21:46 <jungleboyj> I know Lenovo has said "No travel this year'.
14:21:50 <simondodsley> Americans still aren't allowed into Europe
14:21:53 <rosmaita> i may be losing access to it
14:22:02 <rosmaita> so, i need recommendations for what to use
14:22:11 <simondodsley> Zoom
14:22:16 <rosmaita> (barf)
14:22:20 <simondodsley> lol
14:22:35 <rosmaita> though, for lack of anything better, we may need to go with zoom
14:22:42 <rosmaita> so let that be a motivating factor
14:22:43 <jungleboyj> rosmaita:  You are losing Bluejeans access?
14:22:56 <rosmaita> jungleboyj: at some point, i believe so
14:23:11 <rosmaita> switching to google hangouts or whatever they are called nowadays
14:23:20 <rosmaita> but those aren't available in china, i believe
14:23:42 <rosmaita> and i know that some open source developers have objections to zoom
14:23:49 <tosky> rosmaita: there may be a case where you can still used bluejeans though
14:23:53 <tosky> use*
14:23:54 <rosmaita> and i probably would too if i thought carefully about it
14:24:16 <rosmaita> tosky: true, though it's probably time to start looking for a replacement
14:24:20 <tosky> sure
14:24:33 <tosky> but for this PTG we can probably still be covered
14:25:13 <rosmaita> yeah, that's true
14:25:24 <rosmaita> i guess i am panicking
14:25:47 <rosmaita> ok, so let's figure bluejeans for PTG, but will need to come up with something else shortly after
14:25:50 <rosmaita> for the midcycles
14:26:28 <jungleboyj> Maybe a topic for the PTG.
14:26:37 <rosmaita> good idea
14:26:57 <rosmaita> i will add it to ptg, and maybe we can try out some options during one of the sessions or something
14:27:17 <rosmaita> ok, that's all the announcements
14:27:24 <rosmaita> #topic stable release updates
14:27:28 <rosmaita> whoami-rajat: you're up
14:27:32 <whoami-rajat> thanks
14:27:54 <whoami-rajat> So we've already released wallaby on 1st September and i was planning for a victoria release
14:28:10 <whoami-rajat> thanks to jungleboyj who had already reviewed all the victoria patches!
14:28:21 <jungleboyj> \o/
14:28:38 <whoami-rajat> there are some new ones as well but I've filtered out the ones which are included in the wallaby release, they're on the etherpad
14:28:39 <rosmaita> jungleboyj: ++
14:29:00 <whoami-rajat> 1 patch is remaining in cinder and 2 in cinderclient and we are good to release victoria
14:29:07 <whoami-rajat> #link https://etherpad.opendev.org/p/cinder-stable-releases-aug-sept-2021
14:29:14 <jungleboyj> Sweet.
14:29:19 <rosmaita> maybe we should have any stable cores who attend the Festival of Reviews review those patches
14:29:32 <rosmaita> and everyone else work on the XS ones
14:29:38 <whoami-rajat> sounds good
14:29:51 <rosmaita> that way we won't add too much stuff to master
14:30:04 <rosmaita> which isn't necessarily a problem, but you never know
14:30:10 <jungleboyj> Yeah, sounds good.
14:30:16 <rosmaita> ok, thanks whoami-rajat
14:30:23 <whoami-rajat> that's all from me
14:30:38 <rosmaita> #topic discussion on naming issue
14:30:43 <rosmaita> manoj_katari: that's you
14:30:48 <manoj_katari> thanks
14:31:07 <manoj_katari> irrespective of the defualt or custom volume_name_template, this minor code change (https://review.opendev.org/c/openstack/cinder/+/790910/12/cinder/volume/drivers/ibm/storwize_svc/replication.py#171)will only try to handle the length restriction in the storage ,
14:31:50 <manoj_katari> moreover this change is applicable only in case of GMCV target change volume and not the regular volumes.
14:33:50 <rosmaita> ok, so my objection is still that using the official template option supported upstream, it's not true that you won't get naming collisions
14:34:31 <rosmaita> this is from my comment on the patch: The 'name' on the Volume object is generated, not stored, and there doesn't seem to be any length restriction on it (because it's in the config file, not the database).  The generated name is template + string representation of a UUID, and the calling function is slapping on two 4 char prefixes in front of that.  Since 36+8=44, if the config template is longer than 19 chars, we'll exce
14:34:31 <rosmaita> ed the max length limitation of Storwize.
14:35:08 <rosmaita> so if someone chooses a long template, it will push the uuid out of the cutoff length
14:35:51 <manoj_katari> i agree but most of our customers (patched openstack) will use simillar template  'volume-%(display_name).37s-%(id).13s
14:36:06 <rosmaita> yes, but that template is not upstream
14:36:29 <rosmaita> all we allow is for you to interpolate the id
14:37:00 <rosmaita> and "most of our customers" kind of worries me
14:37:23 <manoj_katari> ok
14:37:34 <rosmaita> like i said last week, i don't like this, but i'm willing to drop my -2 if people think i am being unreasonable
14:37:51 <rosmaita> (i definitely won't +2 it though, i think it's a bad idea)
14:38:10 <eharney> maybe we should just add a check that causes the driver to fail to init if the generated names will be too long?
14:38:12 <rosmaita> by "people" i mean "the cinder community"
14:38:16 <eharney> does that help?
14:39:21 <jungleboyj> eharney:  That would sound like a reasonable compromise.
14:39:21 <eharney> (not sure if i have all the details right)
14:40:02 <simondodsley> Pure had to do a lot of messing with long names for PowerVC support - it's not pretty.
14:40:07 <jungleboyj> I was thinking about checking the length of the setting in the config file, but this is really specific to SVC.  So, failing there with an explanation would work.
14:40:22 <jungleboyj> simondodsley:  :-(
14:40:34 <manoj_katari> yes simondodsley
14:40:51 <rosmaita> i think what i suggested was actually based on something i saw in one of the pure drivers
14:41:16 <manoj_katari> sure rosmaita we will try to take your suggestion and come back on it
14:41:27 <simondodsley> let me look at the patch as well
14:41:28 <rosmaita> namely, pull out the middle of the string, leaving the beginning for meaningful prefix info, and the last part from the uuid to keep uniqueness
14:41:40 <rosmaita> simondodsley: that would be helpful
14:42:00 <rosmaita> i don't want to be unreasonable, but i also don't want to merge something that will cause problems later
14:42:07 <manoj_katari> thanks simondodsley and rosmaita
14:42:12 <rosmaita> ok, let's revisit this next week
14:42:16 <manoj_katari> sure
14:42:20 <rosmaita> thanks manoj_katari
14:42:28 <rosmaita> #topic new exception usage
14:42:35 <rosmaita> manoj_katari: another one for you!
14:42:41 <manoj_katari> yes
14:43:26 <manoj_katari> here we wanted a new exception https://review.opendev.org/c/openstack/cinder/+/787262/6/cinder/exception.py#441
14:44:29 <manoj_katari> explictily to specify that volume has some snapshots during retype
14:44:50 <geguileo> manoj_katari: did you want to change the message or the exception class?
14:45:06 <geguileo> I mean, would it be enough to change the exception message?
14:45:49 <manoj_katari> we have modified message already https://review.opendev.org/c/openstack/cinder/+/787262
14:46:03 <manoj_katari> to clearly indcate the user about ongoing flashcopy operations
14:46:33 <geguileo> manoj_katari: what I mean is that you can use the InvalidVolume exception and provide a meaningful message for your case
14:47:13 <geguileo> and I don't see any value in having a specific class for that exception
14:47:19 <rosmaita> right, is the problem that you need to detect a particular exception class somewhere, or that you want a more specific message to the user?
14:47:38 <geguileo> what he said   ;-)
14:47:45 <rosmaita> :)
14:48:20 <geguileo> I don't see it catching that exception except in the test
14:48:41 <manoj_katari> we need a new  exception class
14:50:06 <rosmaita> (not ignoring you, looking at the code)
14:50:09 <eharney> i think this can be handled without needing a new class
14:50:32 <manoj_katari> rosmaita :)
14:50:53 <geguileo> manoj_katari: what for?
14:51:01 <geguileo> we don't see it being necessary anywhere
14:51:34 <geguileo> and if it was used we don't see any reason why it would need to be differentiated from the InvalidVolume class
14:52:25 <rosmaita> another way to ask this, is why not raise InvalidInput at https://review.opendev.org/c/openstack/cinder/+/787262/6/cinder/volume/drivers/ibm/storwize_svc/storwize_svc_common.py#5016 , but with your own message?
14:52:49 <manoj_katari> fine, we will try to use invalidvolume and send the required message through that and i will come back on this
14:52:53 <rosmaita> because i don't see your VolumeHasSnapshot being used in any execpt: statement
14:53:18 <rosmaita> manoj_katari: ok, give that a shot, and if you discover a problem, you can tell us on the review
14:53:30 <jungleboyj> ++ That sounds good.
14:53:39 <manoj_katari> sure! thanks every one for your valuable suggestions :)
14:53:57 <rosmaita> thanks for bringing it up
14:54:13 <rosmaita> #topic deprecate MySQL 5.5
14:54:29 <rosmaita> this is kind of a weird one, i don't know that we have a support statement anywhere
14:54:44 <rosmaita> but, we do have some workarounds due to MySQL 5.5 or earlier not supporting subsecond resolution in datetime fields
14:55:01 <rosmaita> MySQL 5.5 last release was 5.5.62 on 2018-10-22, and its end of support was December 2018
14:55:17 <rosmaita> so we probably shouldn't support its use either
14:55:44 <rosmaita> so my question is, should i say something about this in a release note for xena?
14:56:29 <rosmaita> my second question, is if we say we don't support 5.5, what does that mean about 5.6 (or 5.8) which are also out of support at oracle
14:56:49 <rosmaita> i may have the last 2 numbers incorrect but you see what i mean
14:57:22 <rosmaita> maybe it's better to say nothing, and people assume that they should only use dbs that are supported by the db vendor?
14:57:55 <rosmaita> i don't know if i'm being clear
14:58:34 <rosmaita> basically, if we explicitly say we don't support version X that hasn't been supported for years, will people assume we *do* support any version more recent than X
14:59:08 <simondodsley> i think they will make that assumption
14:59:14 <jungleboyj> simondodsley:  ++
14:59:39 <geguileo> simondodsley: +1
14:59:49 <eharney> is this just about mysql or also mariadb?
14:59:59 <rosmaita> ok, thanks ... i will keep my mouth shut, and then maybe at the ptg we can discuss if we need a db support statement
15:00:19 <rosmaita> eharney: not sure when mariadb started
15:00:20 <geguileo> eharney: mariadb as well
15:00:26 <rosmaita> geguileo: thanks
15:00:26 <eharney> rosmaita: a long time ago
15:00:39 <rosmaita> i remember when there was no mariadb!
15:00:45 <jungleboyj> rosmaita:  That sounds like a good plan.
15:00:50 <rosmaita> but you probably don;t!
15:00:56 <rosmaita> ok, we are out of time, thanks everyone
15:01:15 <jungleboyj> Thanks!
15:01:17 <geguileo> thanks everyone, have a nice rest of the day
15:01:21 <simondodsley> ttfn
15:01:25 <whoami-rajat> thanks!
15:01:39 <rosmaita> #endmeeting