14:00:09 <rosmaita> #startmeeting cinder
14:00:09 <openstack> Meeting started Wed Jul 15 14:00:09 2020 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:13 <openstack> The meeting name has been set to 'cinder'
14:00:16 <jungleboyj> o/
14:00:18 <rosmaita> #topic roll call
14:00:19 <smcginnis> o/
14:00:22 <whoami-rajat> Hi
14:00:25 <enriquetaso> o/
14:00:28 <eharney> hi
14:00:44 <rajinir> hi
14:01:12 <lseki> hi
14:01:15 <rosmaita> hello everyone
14:01:27 <rosmaita> #link https://etherpad.openstack.org/p/cinder-victoria-meetings
14:01:38 <rosmaita> #topic updates
14:01:48 <rosmaita> some upcoming events
14:01:49 <e0ne> hi
14:01:53 <tosky> hi
14:02:48 <rosmaita> ok, well i cannot copy & paste from the etherpad
14:02:56 <rosmaita> so i direct you to the etherpad for links
14:03:10 <rosmaita> openstack 10th anniversary celebration is tomorrow
14:03:25 <rosmaita> berlin summit call for proposals closes on 4 august
14:03:26 <LiangFang> o/
14:03:48 <rosmaita> i sent out a proposal to EOL ocata and pike (we will discuss more later)
14:04:12 <rosmaita> we'll be having the last meeting each month as a videoconference, first one will be 29 july
14:04:23 <rosmaita> and, this week is R-13
14:04:32 <rosmaita> which gives us 2 weeks until milestone 2
14:04:41 <rosmaita> which is notable for the new driver merge deadline
14:04:59 <rosmaita> there are 3 major driver changes that i am aware of at the moment
14:05:07 <rosmaita> (see links on etherpad)
14:05:34 <rosmaita> the hitachi driver looks ready -- final holdup was the CI crashed, but it is operational again
14:05:47 <rosmaita> so top priority is to get that merged
14:05:47 <smcginnis> Just approved.
14:05:52 <rosmaita> thanks!
14:06:00 <rosmaita> ok, the new top priority is
14:06:12 <rosmaita> new "powerstore" cinder driver
14:06:39 <rosmaita> and the other big driver change is that Dell wants to rebrand vxflexos
14:06:48 <rosmaita> which touches a lot of code
14:07:09 <rosmaita> anyway, please keep those in mind
14:07:19 <rosmaita> any other announcements from anyone?
14:08:06 <m5z> hi =]
14:08:35 <rosmaita> #topic victoria specs
14:08:59 <rosmaita> ok, we are a bit late on these
14:09:12 <rosmaita> but the way it's looking is:
14:09:46 <rosmaita> default volume type overrides -- had some API URL naming/structure issues, i think those are settled
14:10:10 <rosmaita> modern compression algos -- depended on a requirements change that has been approved & merged
14:10:14 <rosmaita> so that's ready too
14:10:41 <rosmaita> volume-list-query has been turned into a bug, so it think that one can be abandoned
14:10:58 <rosmaita> revert *any* snap -- we asked them to hold for wallaby
14:11:23 <rosmaita> reset state robustification -- looks good, but i don't think anyone has volunteered to work on it?
14:11:43 <smcginnis> rosmaita: Cinder spec freeze is next week, right?
14:11:56 <rosmaita> i think 2 weeks ago
14:12:28 <rosmaita> we had an extension until friday last week
14:12:31 <smcginnis> Oh right, June.
14:12:59 <rosmaita> yeah, so we are a bit behind on approvals
14:13:43 <rosmaita> sam hasn't updated the "remove quota usage cache" spec, and it's not clear to me that he was going to do the coding for it
14:14:24 <rosmaita> so it's looking like that won't happen in V unless someone here is anxious to work on it?
14:14:42 * rosmaita waits for someone to say they are excited to work on it
14:16:12 <rosmaita> ok, to summarize: please look over "default volume type overrides" and "modern compression algos" -- those are ready
14:16:44 <rosmaita> #topic festival of EOL
14:17:17 <rosmaita> ok, link to the email i sent to the ml on the agenda
14:17:26 <rosmaita> looks like no one wants to keep ocata around
14:17:51 <rosmaita> there is one person who would like to keep pike
14:17:54 <tosky> at least one person is trying
14:17:59 <rosmaita> but i personally have no interest in this
14:18:16 <smcginnis> Ocata was released Feb 2017.
14:18:19 <rosmaita> so what i want to ask is, is there any cinder core present who wants to "adopt" stable/pike
14:18:21 <smcginnis> Pike was released in August.
14:18:24 <e0ne> +1 to mark pike as EOL
14:18:46 <rosmaita> i really don't have the psychic energy to worry about pike
14:19:00 <rosmaita> because we have plenty of other gate breakages to worry about
14:19:13 <rosmaita> so, my feeling is, even if there is a patch to fix the pike gate right now
14:19:31 <rosmaita> i don't see the point in merging it if we are going to EOL it next week
14:19:36 <smcginnis> I've been trying to pay some attention to stable branches, but with less time and more issues on more recent branches, I don't think I can spend much time on pike.
14:20:15 <rosmaita> yeah, and i don't see the point it keeping it open with so many other open branches
14:20:43 <smcginnis> We have a hard enough time getting people to keep master working. :)
14:20:54 <rosmaita> exactly
14:21:01 <rosmaita> ok, so to summarize:
14:21:16 <e0ne> smcginnis: +1
14:21:47 <rosmaita> unless a specific cinder core steps forward to adopt stable/pike as their own personal project, I plan to ask for it to be EOL'd as outlined in that email
14:22:05 <rosmaita> meaning, i will propose the EOL patch on 22 july
14:22:44 <rosmaita> so that gives people 1 more week to think about this, but the log for this meeting indicates what the general consensus is
14:22:55 <rosmaita> several people vocally opposed, and no one in favor
14:23:00 <eharney> +1 to EOLing pike
14:23:03 <rosmaita> of keeping it open i mean
14:23:35 <jungleboyj> I think it is ok to plan to EOL it.
14:23:45 <rosmaita> ok, we are almost out of cores!
14:23:59 <rosmaita> looks like no one wants to adopt pike
14:24:16 <rosmaita> #topic __DEFAULT__ type discussion continued
14:24:23 <rosmaita> whoami-rajat__ you have the floor
14:24:29 <whoami-rajat___> thanks rosmaita
14:24:35 <whoami-rajat___> Hi everyone
14:24:47 <whoami-rajat___> this topic is just to continue the discussion we had last week
14:25:04 <whoami-rajat___> I've created an etherpad regarding the points discussed last week
14:25:29 <whoami-rajat___> In summary it is, what the actual design was vs what suggestions were made last week
14:25:39 <whoami-rajat___> #link https://etherpad.opendev.org/p/__DEFAULT___type_discussion
14:27:02 * whoami-rajat___ waits for people to read etherpad
14:27:39 * whoami-rajat___ also realizes using last week in every sentence
14:28:20 <rosmaita> i think the issue that came up on the bug is, an operator can set a default type, but a user can still create volumes of type __DEFAULT__ which is exactly what the operator does not want
14:29:06 <whoami-rajat___> yep, but the initial idea was it is also a type that can have properties and can be used as a normal default
14:30:50 <rosmaita> yeah, but kind of doesn't work if the operator wants to change the default type maybe because the backend is full or got a new one or something
14:31:10 <rosmaita> shouldn't have to change the properties of __DEFAULT__ to do that
14:31:58 <whoami-rajat___> yeah, for that the solution is they can set a different default_volume_type in cinder.conf
14:32:29 * smcginnis still thinks __DEFAULT__ should not be returned in API calls and should not allow setting extra specs
14:32:40 * rosmaita agrees with smcginnis
14:33:48 <eharney> a lot of these questions seem to be just around whether __DEFAULT__ is actually a volume type or a special thing
14:34:22 <whoami-rajat___> i more see this as a documentation issue that operators and users aren't aware what the __DEFAULT__ type is, and if we want to do the required changes to not return it, i don't see a proper plan to do it
14:34:59 <smcginnis> I think we've lost sight of why it was proposed to be added in the first place. It is (or was) perfectly valid for someone to create a volume without specifying a volume type. But our code assumed there would be one, so we wanted to have a placeholder to make sure we could keep making that assumption.
14:35:18 <smcginnis> It never should have been something exposed to an end user and definitely should not have been something they were allowed to modify.
14:35:32 <eharney> that is not the thinking i had when we started this
14:36:12 <rosmaita> eharney: please say more, because i share smcginnis's impression
14:36:25 <jungleboyj> smcginnis:  ++
14:36:41 <geguileo> eharney: +1
14:36:47 <jungleboyj> We just didn't think about the impact of being able to see it externally.
14:36:47 <eharney> my impression was that life would be simpler if volumes all had types, so we would just make a type that we could give to existing untyped volumes, and going forward all of them would have types
14:36:50 <geguileo> that wasn't the impression I had either
14:37:04 <eharney> i'm not sure why there is this other story about this not being a real volume type and being handled as a special case everywhere
14:37:13 <eharney> that isn't necessary to achieve what we wanted to achieve
14:38:08 <smcginnis> What I think we wanted to achieve is to stop playing whack-a-mole with places in the code where we expected a volume type to be associated with a volume. So we wanted to have something that would be used when none was specified.
14:38:35 <eharney> my theory was that there just wouldn't be a "none" anymore
14:39:38 <whoami-rajat___> The idea that all untyped volumes will be migrated to __DEFAULT__ type and users won't be able to see it, i don't see any straightforward way of doing this. also the type always exists so users can show it ? or try to create a type with this name but fail ?
14:39:40 <eharney> handling it as a special case also leads to other issues to think through... what do you show for "volume show", how do you not confuse people who are doing a retype, etc
14:40:19 <smcginnis> whoami-rajat___: That was part of the reason for naming it __DEFAULT__. To avoid the change someone would try to create a volume type named Default or something.
14:40:58 <smcginnis> eharney: I would think no volume type, since they did not specify one and no default volume type was configured.
14:41:12 <whoami-rajat___> smcginnis: i think the idea was there wouldn't be any existing type named __DEFAULT__ before upgrade so it doesn't clash with this type
14:41:21 <smcginnis> Right
14:41:31 <smcginnis> And less likely someone would try to create that type later on.
14:42:16 <whoami-rajat___> smcginnis: but then again the first part is still very complex for me
14:42:33 <smcginnis> Which first part?
14:43:13 <whoami-rajat___> if a volume was migrated from None to __DEFAULT__ type, what do we display volume_type in volume show command for that volume?
14:43:21 <smcginnis> Nothing.
14:43:32 <smcginnis> They have not assigned the volume a volume type.
14:43:54 <smcginnis> We are just using __DEFAULT__ internally so we don't blow up because we aren't smart enough to write out code to handle not having a type.
14:44:03 <eharney> is there some benefit to keeping around the idea of volumes with no type other than the fact that it was like that before?
14:44:51 <eharney> my impression is that in Serious Real Life Deployments (tm) most people are using types anyway
14:44:57 <smcginnis> Why should we require a type? If that's the case, let's drop all this and fail any volume creation if a type isn't defined and set as the default in cinder.conf if they have not explicitly provided it.
14:46:06 <jungleboyj> :-)
14:46:41 <whoami-rajat___> I've an idea, make __DEFAULT__ a normal type, allow users to delete it but the condition is there should atleast exist 1 type in the deployment?
14:47:16 <rosmaita> well, that plus the default_volume_type is defined
14:47:24 <smcginnis> 1 type in the deployment and the default_volume_type set.
14:47:30 <smcginnis> rosmaita: ++
14:48:43 <rosmaita> whoami-rajat__ that would address the request in the bug
14:49:13 <whoami-rajat___> rosmaita: yep, i think that's what the operator wanted in the bug
14:49:14 <rosmaita> the operator has defined everything the way they want it, and just want to get rid of __DEFAULT__ since it is confusing customers
14:49:55 <rosmaita> at the risk of being accused of being a bikeshedder, let's think about this some more
14:50:15 <rosmaita> but whoami-rajat__ please update your etherpad with the latest proposal
14:50:16 <whoami-rajat___> but this goes for all types, any type before delete would make a check for default_volume_type set and atleast 1 type in deployment
14:50:34 <rosmaita> and the value of default_volume_type exists
14:50:41 <rosmaita> yes
14:50:43 <jungleboyj> Makes sense.
14:50:49 <whoami-rajat___> rosmaita: yep
14:51:24 <whoami-rajat___> ok, i will think of a way of implementing  this with no new bugs and update the etherpad
14:51:33 <rosmaita> thanks!
14:51:35 <whoami-rajat___> would appreciate any more suggestion on the same
14:51:55 <rosmaita> yes, let's all think about corner cases so we don't have to do this again
14:52:04 <whoami-rajat___> yep
14:52:09 <whoami-rajat___> thanks everyone
14:52:42 <rosmaita> #topic any reason to keep non-voting jobs in the stable branches
14:52:44 <smcginnis> Now we should change the default name to DEFAULT since we aren't trying to hide it. :]
14:53:02 <rosmaita> that is a real question
14:53:21 <rosmaita> i just noticed that they use resources, and fail a lot
14:53:24 <whoami-rajat___> smcginnis: will add that suggestion as well
14:53:39 <rosmaita> whoami-rajat__ please don't
14:54:05 <smcginnis> Yeah, probably too late now.
14:54:29 <whoami-rajat___> rosmaita: ok :P
14:54:30 <smcginnis> rosmaita: I think we might need to keep some of the non-voting jobs, at least in more recent stable branches.
14:54:35 <jungleboyj> Yeah, lets not change any more on that.
14:54:38 <smcginnis> But we can probably get rid of some of them.
14:54:40 <eharney> as someone noted in the etherpad, the nfs job probably should be voting
14:54:50 <eharney> rally, i would question
14:55:22 <eharney> pylint is non-voting but helps us review backports better so i'd prefer to keep that one
14:55:31 <tosky> the nfs job has an identity crisis right now, we may need to ask infra because it gets stuck and it doesn't even return logs in some instances
14:55:36 <smcginnis> bandit can probably go.
14:55:45 <lseki> I'd ask to keep the nfs job, at least until the online extend bug is fixed
14:56:13 <smcginnis> lvm-multibackend can probably go.
14:56:23 <tosky> smcginnis: is a separate bandit job needed? In sahara we merged it with the pep8 job long ago
14:56:38 <tosky> smcginnis: oh, why should lvm-multibackend go?
14:56:43 <eharney> agreed re: bandit
14:56:47 <tosky> we don't have other multibackend jobs right now iirc
14:56:49 <smcginnis> tosky: I think we originally had it there too, but then separated out bandit.
14:57:02 <rosmaita> tosky: for a while bandit was so unstable, that it kept breaking things
14:57:08 <smcginnis> ++
14:57:10 <rosmaita> they had poor release control
14:57:22 <tosky> but probably it's not the case anymore? Anyway
14:57:30 <tosky> I'm more concerned about the lvm-multibackend
14:57:33 <eharney> i would ask whether the bandit job has ever caught something interesting on a backport.  i would bet not
14:57:37 <smcginnis> True. We could probably merge it now.
14:57:47 <smcginnis> eharney: Very true too.
14:58:22 <rosmaita> running low on time
14:58:27 <rosmaita> i propose:
14:58:50 <rosmaita> i will put up a patch removing all non-voting jobs from stable/ussuri, and we can fight it out on the review
14:59:17 <rosmaita> i am happy to leave some, or promote stable ones
14:59:31 <rosmaita> but don't want to run jobs that nobody looks at
14:59:59 <rosmaita> i won't put a DNM on the patch, because i imagine it will get immediate -2s :)
15:00:05 <rosmaita> and that's all
15:00:12 <rosmaita> thanks everyone, make way for horizon
15:00:14 <rosmaita> #endmeeting