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