16:00:46 <jungleboyj> #startmeeting Cinder
16:00:47 <openstack> Meeting started Wed Apr 17 16:00:46 2019 UTC and is due to finish in 60 minutes.  The chair is jungleboyj. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:50 <openstack> The meeting name has been set to 'cinder'
16:00:50 <jungleboyj> :-)
16:00:58 <whoami-rajat> Hi
16:01:01 <smcginnis> o/
16:01:18 <jungleboyj> courtesy ping jungleboyj diablo_rojo, diablo_rojo_phon, rajinir tbarron xyang xyang1 e0ne gouthamr erlon tpsilva ganso patrickeast tommylikehu eharney geguileo smcginnis lhx_ lhx__ aspiers jgriffith moshele hwalsh felipemonteiro lpetrut lseki _alastor_ whoami-rajat yikun rosmaita enriquetaso hemna _hemna
16:01:30 <_alastor_> o/
16:01:32 <rajinir> o/
16:01:33 <rosmaita> o/
16:01:37 <jungleboyj> Multi-tasking PTL.
16:02:04 <e0ne> hi
16:02:13 <jungleboyj> @!
16:02:30 <jungleboyj> Booo!  hemna_ pewp is gone again.
16:02:32 <eharney> hi
16:02:43 <hemna_> mep
16:03:04 <hemna_> boo :(
16:03:10 <jungleboyj> Give people another minute to connect.
16:03:24 <hemna_> hrmm maybe pewp is down..../me checks
16:03:38 <walshh_> hi
16:03:44 <jungleboyj> He he.
16:03:53 <jungleboyj> Ok, going to get started.
16:03:56 <jungleboyj> Hello all.
16:03:57 <enriquetaso> o/
16:04:06 <jungleboyj> I am back.  Thank you smcginnis for covering last week.
16:04:15 <jungleboyj> #topic announcements
16:04:16 <enriquetaso> welcome back!
16:04:17 <whoami-rajat> jungleboyj: welcome back!
16:04:25 <jungleboyj> Thank you!
16:04:40 <jungleboyj> So, I am working on getting the Train PTG planned.
16:04:57 <jungleboyj> #link https://etherpad.openstack.org/p/cinder-train-ptg-planning
16:05:14 <jungleboyj> I see that a few topics have been added.  Thank you very much.
16:05:33 <jungleboyj> Please keep the topics coming so we can have a productive PTG.
16:06:13 <jungleboyj> I am going to work on going through old discussions as well and try to add things as appropriate.
16:06:41 <jungleboyj> Also, we have our Dinner for the team at the Summit.
16:06:51 <jungleboyj> Tuesday night before the whole Summit event.
16:07:03 <jungleboyj> Have a number of people that have indicated interest in attending.
16:07:06 <jungleboyj> Thank you!
16:07:17 <jungleboyj> Please add your name if interested as I will make reservations soon.
16:07:33 <jungleboyj> #link https://etherpad.openstack.org/p/cinder-train-dinner-plan
16:07:45 <jungleboyj> A happy announcement.
16:07:59 <jungleboyj> I have put an e-mail out proposing rosmaita for Core!  :-)
16:08:10 <jungleboyj> Excited to have another person to propose.
16:08:10 <smcginnis> Woot! Nice work rosmaita
16:08:15 <jungleboyj> smcginnis: ++
16:08:17 <eharney> hooray
16:08:22 <enriquetaso> rosmaita++
16:08:26 <enriquetaso> \o/
16:08:29 <jungleboyj> rosmaita: Thank you for joining us and coming up to speed during the last release!
16:08:31 * rosmaita blushes
16:08:37 <hemna_> awesome
16:08:59 <jungleboyj> Take a look at my note and if there are no concerns I will add him to the list next week.
16:09:27 <jungleboyj> rosmaita:  Looking like you won't have problems.  :-)
16:09:50 <jungleboyj> Final announcement.
16:10:07 <jungleboyj> I am working on getting the Forum Etherpads in place.  I think we only have a couple of topics.
16:10:28 <jungleboyj> I will send out an e-mail once the etherpads are up so people can add topics.
16:11:19 <jungleboyj> So, that is it for announcements.
16:11:45 <jungleboyj> #topic stable branch releases update
16:11:50 <jungleboyj> rosmaita:  All yours.
16:12:01 <rosmaita> I figured it would be worth doing our monthly stable releases before the PTG.  Three things:
16:12:15 <rosmaita> 1 - cinder stable/rocky has 2 reviews sitting with 1 +2 ... i will propose 13.0.5 tomorrow, would be nice if a stable core could +W or -2 them in the meantime
16:12:26 <rosmaita> 2 - os-brick had only 1 unreleased change in rocky & queens, but i figured the point of the monthly releases is to make sure stuff doesn't sit, so i put up a release patch for each
16:12:39 <rosmaita> 3 - for cinderclient, looks like sean has a bunch of "raise API max" patches on master that will need to be backported to stein & rocky before we do a new release? (just want to verify that we want to hold the releases from stein & rocky for those)
16:12:55 <rosmaita> oops, i forgot the link to the etherpad
16:13:08 <rosmaita> #link https://etherpad.openstack.org/p/cinder-releases-tracking
16:13:17 <jungleboyj> :-)
16:13:38 <rosmaita> so the main question is 3, the others are points of information
16:14:45 <hemna_> just for consistency ?
16:14:47 <eharney> i was trying to become more clear on those cinderclient api max patches -- do they actually get in the way of a couple of features working?
16:15:04 <rosmaita> that was my question too
16:15:37 <jungleboyj> Ok.  The rocky ones are on their way.
16:15:52 <rosmaita> ok
16:16:18 <jungleboyj> So, the changes that Sean put up are required to expose new functions that went out in the server in Stein.
16:16:38 <smcginnis> eharney, rosmaita: Otherwise the client doesn't think it can talk that level: https://opendev.org/openstack/python-cinderclient/src/branch/master/cinderclient/api_versions.py#L312
16:16:40 <eharney> and roky
16:16:42 <eharney> rocky*
16:17:01 <jungleboyj> There is stuff that goes back to Rocky?
16:17:17 <rosmaita> ok, we should def get those in before a release
16:17:24 <jungleboyj> rosmaita:  ++
16:18:28 <jungleboyj> Do we then need to backport those?
16:18:38 <jungleboyj> Trying to remember what we did the last time we made this mistake.
16:18:50 <eharney> so the stein one doesn't appear to actually have much of an effect
16:19:26 <eharney> well, i guess it affects behavior, just doesn't need client changes, never mind
16:20:40 <jungleboyj> But need to enable the client for that level to be able to use the server side support.
16:21:29 <jungleboyj> smcginnis:  Do you remember what we did in the past after they merged to master?
16:21:37 <smcginnis> I think we backported them.
16:21:39 <smcginnis> It's a
16:21:53 <smcginnis> "new feature" for the stable branch, but for missing functionality.
16:22:01 <jungleboyj> Ok, I thought that was the case.
16:22:14 <smcginnis> And really just the one adds new stuff. The other two just set the max version correctly.
16:22:29 <jungleboyj> Right.
16:22:33 <smcginnis> If we want, we can skip the one and just bump the version. Though that would be confusing.
16:22:44 <smcginnis> At least the max rocky version should get backported all the way.
16:22:56 <jungleboyj> Ok, lets get those in, backport and then do releases.
16:23:01 <eharney> will this need a minor version bump to handle the fact that it's a small compat change?
16:23:17 <smcginnis> I don't think we can.
16:23:26 * jungleboyj can hear jgriffith groaning
16:23:33 <smcginnis> Usually we do a minor bump for the next cycle, so there's only room for a bugfix bump.
16:23:47 <rosmaita> yes, that's the case here
16:23:48 <smcginnis> You could argue it's a bug that the client doesn't think it can talk to the server.
16:24:50 <jungleboyj> I believe that was the decision in the past as well.
16:25:10 <jungleboyj> People may grumble at us but I don't know of another way to do it.
16:25:31 <smcginnis> We have a few other agenda topics, so I think we can hash out any concerns later.
16:25:47 <rosmaita> sounds good, that's all from me
16:26:00 <eharney> the other way to do is it to bump up both the stein version and the master version, but, ok
16:26:26 <smcginnis> eharney: Not sure I follow.
16:26:37 <jungleboyj> Ok.  Lets move on and has that out when the release is proposed.
16:26:39 <rosmaita> i will keep the etherpad updated, we can discuss there and/or on the release patches
16:27:08 <jungleboyj> Cool.
16:27:15 <jungleboyj> rosmaita: Thank you for doing that work!
16:27:27 <jungleboyj> @!
16:27:50 <jungleboyj> hemna_:  Your pewp is still broken.  ;-)
16:28:00 <hemna_> yah working on it
16:28:05 <hemna_> container pain
16:28:21 <jungleboyj> #topic Untyped volumes to default vol type
16:28:26 <jungleboyj> whoami-rajat:
16:28:56 <whoami-rajat> The popular question appearing on the specs from every reviewer is the default type shouldn't be containing any extra_specs, the possible case i think to handle this is we shouldn't allow default_type to be updated but i think it's better to be discussed at the meeting.
16:29:20 <hemna_> yah I raised that issue I think.
16:29:33 <whoami-rajat> hemna_: geguileo and eharney  too
16:29:34 <hemna_> the problem is assigning that default type to untyped volumes
16:29:38 <jungleboyj> whoami-rajat:  Ok.  I need to catch up on that spec.
16:29:50 <hemna_> if that type has attributes, it would kick off a retype operation which could result in a migration as well.
16:29:53 <whoami-rajat> #link https://review.openstack.org/#/c/651480/
16:29:53 <_pewp_> [ Gerrit Code Review ] - review.openstack.org
16:29:53 <hemna_> it just gets ugly
16:30:08 * jungleboyj laughs
16:30:10 <e0ne> what if operators already configured default volume type with some extra specs?
16:30:34 <hemna_> e0ne: then there shouldn't be any untyped volumes
16:30:40 <eharney> yeah, if the default volume type already has specs, they'll be used
16:30:41 <hemna_> the question I think is the untyped volumes
16:31:16 <jungleboyj> hemna_:  I think is a fair argument.
16:31:29 <smcginnis> Maybe the more correct thing to do is just make sure we actually handle untyped volumes right since it's a valid case.
16:32:13 <hemna_> The only conflict is if the name we are picking for default type is the same as what the operated has named
16:32:22 <eharney> right
16:32:52 <jungleboyj> hemna_:  That could be handled as an upgrade check?
16:32:56 <hemna_> we could name it OMGWTFBBQ
16:33:04 <jungleboyj> He he.
16:33:08 <whoami-rajat> hemna_: should we be using a constant UUID format name to avoid that case?
16:33:13 <jungleboyj> Or that.
16:33:20 <eharney> we could just implement the "retype" from None -> default as a db update and not a full retype operation, and don't do it if the default type has extra specs in it
16:33:27 <jungleboyj> OMGBackYardBBQ
16:33:30 <eharney> this would cover the intended cases and also dodge breaking people in that odd case
16:33:52 <eharney> there's no reason it has to be a full retype/migration call if we design it so that it would never migrate volumes anyway
16:33:54 <hemna_> eharney: that only works if the type has no attributes
16:34:03 <eharney> right, which is the primary use case for this
16:34:09 <smcginnis> Or we could just fix our code where we assume there's going to be a type. :)
16:34:22 <eharney> ...
16:34:31 <hemna_> if we guarantee the name we pick is unique, then there is no reason to worry about the attributes, since it will be empty
16:34:42 <e0ne> hemna_: +1
16:34:45 <hemna_> smcginnis: we have a patch out for 1 known issue
16:34:51 <hemna_> the question is the unknown issues still
16:34:56 <eharney> but then you end up with a usability/documentation mess
16:35:04 <eharney> i'm not sure that's worthwhile
16:35:26 <hemna_> as a side topic, we don't really have any documentation on volume types as a whole.
16:35:28 <hemna_> s m h
16:35:48 <jungleboyj> hemna_:  Yeah, one of our biggest things but not well documented.
16:35:51 <jungleboyj> :-(
16:35:54 <hemna_> what they are, how/why they can be used.  I think everyone just assumes that you use a type to associate it with a specific backend.
16:36:09 <jungleboyj> hemna_:  True.
16:36:15 <whoami-rajat> eharney: i think a unique name is a simpler way to cover a lot of cases whereas handling case of retype might be just 1 of the problems.
16:36:15 <e0ne> can we just add a pre-upgrade check and force operators to retype untyped volumes?
16:36:25 <smcginnis> So we identified one issue that's been out there for years and we're afraid there may be more? If there are, no ones hitting it often enough to report it, and if they do, we fix it once it's identified.
16:36:38 <eharney> a unique name is making things complicated for little benefit
16:36:53 <jungleboyj> e0ne: That could be another approach.  That could be less user friendly though.
16:37:19 <smcginnis> The bike shed should be blue!
16:37:22 <hemna_> e0ne:I'm not sure that'd go over well with distros......
16:37:58 <hemna_> so I suppose smcginnis is arguing against forcing volumes to have a type, and we do nothing (other than fix bugs)
16:37:59 <jungleboyj> hemna_:  ++
16:38:27 <smcginnis> hemna_: That seems like the better approach to me.
16:38:28 <eharney> and the benefit of continuing to support volumes with no type is... we get to be lazier instead of implementing this?
16:38:32 <e0ne> default_volume_type=UNTYPED
16:38:37 <hemna_> or we could just do what folks do in irc for nicknames  'hemna, hemna_, hemna__'
16:38:39 <eharney> i'm not convinced that untyped volumes actually benefits any users
16:38:39 <smcginnis> Rather than introducing a bunch of new issues.
16:38:43 <hemna_> if you can't find a unique there......
16:39:07 <jungleboyj> The untyped volumes are very confusing IMHO.
16:39:08 <e0ne> hemna_: please, stop forking yourself :)
16:39:16 <whoami-rajat> eharney:  i think of a case when pre-created default type contains extra specs related to a specific backend. won't every of the spec cause an issue for untyped volumes created in that backend ?
16:39:16 <smcginnis> hah
16:39:21 * jungleboyj giggles
16:39:37 <_erlon_> smcginnis: +1, I have seen a few bugs around the issue, but nothig that justify this change if it causing this much trouble
16:39:39 <eharney> whoami-rajat: i can think of a lot of cases, but we can also safely implement the useful cases
16:40:16 <eharney> _erlon_: you say "justify this change" and "this much trouble" like it's an earth-shattering effort or something...?
16:40:32 <smcginnis> It sure seems to be a bigger effort than I think folks thought at first.
16:40:52 <jungleboyj> whoami-rajat:  You put this topic on the PTG list.  Right?
16:40:54 <hemna_> I dunno, I think this is just a matter of either fixing an existing bug, and backporting it, or a simple way of finding a unique/useful name at db migration such that the untyped -> default type is nothin more than a db sql update.
16:41:02 <smcginnis> What about if they did x? What about Y? Should we call it "pewp"? This is a bit nutty.
16:41:03 <whoami-rajat> jungleboyj: yep
16:41:12 <hemna_> if we have a unique name, there is almost no effort really
16:41:21 <hemna_> sql update....done.
16:41:37 <hemna_> it seems quite simple
16:41:37 <rosmaita> sounds like we need to discuss this at the PTG
16:41:41 <_erlon_> eharney: it seems that upgrading and avoiding naming conflicts might bring quite a lot of problems
16:41:41 <e0ne> hemna_:+1
16:41:44 <eharney> right, i'm missing what is supposedly so hard about this
16:41:50 <hemna_> eharney:+1
16:41:55 <smcginnis> Then announce in the release notes that "__DEFAULT__" is a reserved volume type name, make it that, and be done with this.
16:42:05 <hemna_> I'm good with that
16:42:06 <jungleboyj> eharney:  Yeah.
16:42:13 <eharney> well that's what we were going to do, just that it was going to be "default" instead of "__DEFAULT__"
16:42:14 <jungleboyj> smcginnis:  I am good with that too.
16:42:14 <_erlon_> eharney: not earth-shattering, Im just comparing to hte problems of having untyped volumes
16:42:40 <jungleboyj> __DEFAULT__ makes sense and is unlikely to conflict with anything.
16:42:42 <smcginnis> "default" seems like it would have more risk of a conflict with an existing type.
16:42:45 <jungleboyj> Add a release note.
16:42:51 <jungleboyj> Do an upgrade check.
16:42:57 <eharney> i already explained above how to handle conflicts w/ existing types
16:43:03 <hemna_> smcginnis:+1
16:43:11 <hemna_> __DEFAULT__ seems safer
16:43:20 <smcginnis> "Before upgrading, if you have a volume type named WTF, it must be renamed."
16:43:29 <jungleboyj> ++
16:44:34 <jungleboyj> Ok, so I think we can stop bike shedding.
16:44:47 <jungleboyj> Otherwise the reactor is going to melt down.
16:44:51 <eharney> well, now that we decided we actually want a bike shed, yeah
16:44:58 <jungleboyj> :-)
16:45:03 <whoami-rajat> we've created a group-type migration before for migrating consistency groups to generic vol groups, i'm not sure if it faced much issues with the naming.
16:45:05 <jungleboyj> Bike sheds are the bees knees
16:45:44 <jungleboyj> whoami-rajat:  Can you get the spec updated and we can discuss further at the PTG if necessary.
16:46:03 <whoami-rajat> jungleboyj: ok
16:46:24 <jungleboyj> Cool.  Thanks.
16:46:26 <whoami-rajat> just to be clear, we agreed on __DEFAULT__ ?
16:46:34 <jungleboyj> whoami-rajat:  I think that is good.
16:46:44 <jungleboyj> whoami-rajat:  Remind me, will you be at the PTG?
16:46:44 <whoami-rajat> ok
16:47:09 <whoami-rajat> jungleboyj: i won't be making this time. but will connect remotely.
16:47:30 <jungleboyj> Ok.  So, if there are topics you want covered at a particular time for you please let me know in the etherpad.
16:47:31 <eharney> we'll cycle around on the name again once the spec is up to date with the general idea
16:47:42 <jungleboyj> eharney:  ++
16:47:48 <whoami-rajat> jungleboyj: sure, thanks.
16:47:55 <jungleboyj> #topic Review of Specs before Train PTG.
16:48:22 <jungleboyj> So, just a reminder that looking through our outstanding specs can make time at the PTG more productive.
16:48:27 <jungleboyj> Please make some time to do that.
16:48:55 <jungleboyj> I haven't looked in a while so I will do so.
16:49:08 <jungleboyj> I think that is all I had on that unless there are others that want to pile on.
16:49:20 <_erlon_> jungleboyj: have just added a topic there. Can you manage to put that on thu or friday?
16:49:31 <_erlon_> jungleboyj: wont be able to attend on sat
16:49:52 <jungleboyj> _erlon_:  Ok.  Don't expect there to be a lot of discussion on Saturday so we should be fine.
16:50:11 <_erlon_> jungleboyj: nice, thanks
16:50:13 <jungleboyj> I am going to be exhausted after a full week of Summit and PTG.
16:50:39 <jungleboyj> #topic Placement Discussion
16:50:57 <jungleboyj> So, has anyone been tracking impacts of the placement work on Cinder?
16:51:15 <jungleboyj> Way back in Atlanta we met with the team on this.
16:51:44 <jungleboyj> I don't think at lot has happened here other than talking about how they use the DB.
16:52:05 <smcginnis> IIRC, we determined it doesn't help Cinder, but we could publish our resource usage to placement for other services to be able to query.
16:52:08 <e0ne> I think, it's a good time to start discussion again since it's a separate project now
16:52:23 <jungleboyj> There has been discussion on the mailing list but didn't see Cinder input.
16:52:39 <jungleboyj> smcginnis:  That sounds familiar.
16:53:45 <e0ne> #link https://review.openstack.org/#/c/559718/
16:55:16 <jungleboyj> Hmmm.  Ok.
16:55:59 <jungleboyj> So, maybe I will reach out to the Placement group and see if they want to meet with us to discuss anything.  If not, I will let it be for now.
16:56:46 <jungleboyj> See what cdent thinks.
16:57:07 <jungleboyj> Given the silence it doesn't appear of great interest to anyone here.
16:57:45 <jungleboyj> Moving on then.
16:58:05 <jungleboyj> #topic Possible dinner location for team meeting at the Summit
16:58:23 <jungleboyj> #link http://www.rheinhausdenver.com/menus
16:58:42 <jungleboyj> This looks like our kind of place and it is about a mile away so within walking distance.
16:58:56 <rosmaita> i am curious to see how giant a "giant pretzel" is
16:59:04 <jungleboyj> :-)
16:59:29 <jungleboyj> Anyone vote no for that place?  If not, I will make it official.
16:59:36 <smcginnis> Looks good to me.
17:00:01 <hemna_> they have Bier, do we need anything else?
17:00:06 <jungleboyj> Ok.  I will put it in the etherpad.
17:00:08 <jungleboyj> hemna_:  ++
17:00:17 <jungleboyj> I will make a reservation later this week.
17:00:18 <e0ne> :)
17:00:25 <jungleboyj> Ok.  So, that is time.
17:00:31 <jungleboyj> Thanks everyone for joining.
17:00:36 <jungleboyj> #endmeeting