16:00:04 <jungleboyj> #startmeeting cinder
16:00:06 <openstack> Meeting started Wed Apr 11 16:00:04 2018 UTC and is due to finish in 60 minutes.  The chair is jungleboyj. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:09 <openstack> The meeting name has been set to 'cinder'
16:00:23 <jungleboyj> Courtesy ping:  jungleboyj DuncanT diablo_rojo, diablo_rojo_phon, rajinir tbarron xyang xyang1 e0ne gouthamr thingee erlontpsilva patrickeast tommylikehu eharney geguileo smcginnis lhx_ lhx__ aspiers jgriffith moshele hwalsh felipemonteiro lpetrut
16:00:28 <Swanson> Hello.
16:00:29 <ganso> hello
16:00:37 <tommylikehu> hello
16:00:37 <eharney> hi
16:00:41 <jungleboyj> @!
16:00:41 <_pewp_> jungleboyj (¬_¬)ﾉ
16:01:19 <e0ne> hi
16:01:24 <geguileor> hi!
16:01:26 <tbarron> hi
16:01:29 <smcginnis> o/
16:01:39 <lseki> hi
16:02:01 <jungleboyj> Cool.  Looks like we have a good crowd here.
16:02:05 <jungleboyj> Lets get started.
16:02:15 <jungleboyj> #topic announcements
16:02:26 <jungleboyj> Thank you to smcginnis for running the meeting last week.
16:02:38 <jungleboyj> Ian thanks you for freeing me up for his birthday lunch.  :-)
16:02:58 <jungleboyj> I don't have a lot announcement wise.
16:03:10 <rajinir> hi
16:03:21 <jungleboyj> Hopefully you all saw the tweets and e-mails about the reduced hotel prices for the Summit.
16:03:50 <jungleboyj> Hope to see some of you there.
16:04:27 <jungleboyj> Also, the TC nomination period is open.  Have seen notes on the ML about that including the fact that smcginnis  will be running again.
16:04:40 <tommylikehu> great
16:04:48 <jungleboyj> ++
16:04:53 <e0ne> jungleboyj: +1
16:05:22 <smcginnis> Everyone has a week if they'd like to put in their name too. :)
16:05:26 <jungleboyj> Also just to make people aware that Rocky-1 is already coming up quickly.
16:05:47 <jungleboyj> Doesn't close anything down for Cinder, but bring it up for awareness.
16:06:15 <smcginnis> jungleboyj: So no Cinder-specific deadlines for Rocky-1?
16:06:15 <jungleboyj> Ok, moving on.
16:06:38 <jungleboyj> Let me look.  I don't think we have anything for Rocky-1
16:07:14 <e0ne> at least, we don't have anything at https://releases.openstack.org/rocky/schedule.html
16:07:34 <jungleboyj> Nope, Nothing until  .... oops, I thought I had put up the patch for that.
16:07:43 * jungleboyj needs to do that after the meeting.
16:08:33 <jungleboyj> #action jungleboyj  to update the rocky release schedule
16:08:43 <jungleboyj> It will look the same as Queens:
16:08:47 <jungleboyj> #link https://releases.openstack.org/queens/schedule.html
16:09:34 <jungleboyj> #topic Rocky Priorities Review
16:10:11 <jungleboyj> I didn't get a chance to go through this before the meeting.
16:10:37 <e0ne> nothing from me on this topic
16:10:45 <jungleboyj> Anyone have any updates to note in here?  I think the FCZM update is done now.
16:10:50 <jungleboyj> Oh, but the merge failed.
16:10:58 <e0ne> I started rebase my backup-related patches
16:11:10 <e0ne> they'll be on gerrit this week
16:11:33 <jungleboyj> hemna:  hemna_  You need to rebase the FCZM patch.
16:11:47 <jungleboyj> e0ne:  Good.
16:12:45 <jungleboyj> I will try to find some time to go through the list and get things updated.
16:12:57 <jungleboyj> Need to do some spec reviews and try to get those wrapped up.
16:13:34 <jungleboyj> #topic HA Development Progress.
16:13:40 <jungleboyj> geguileor:  Any updates here?
16:13:49 <geguileor> nop
16:13:54 <jungleboyj> :-(  Ok
16:14:22 <jungleboyj> e0ne: Where are things left on the scheduler/database discussion?
16:15:05 <e0ne> jungleboyj: looks like we moved to placement discussion there
16:15:24 <jungleboyj> Ok, so that is on hold until after we talk about it at the Forum?
16:15:40 <e0ne> I need to sync with tommylikehu on this to get our specs up to date
16:15:49 <tommylikehu> oh
16:16:11 <tommylikehu> this one? https://review.openstack.org/#/c/559718/
16:16:13 <e0ne> jungleboyj: sounds readonable
16:16:44 <e0ne> tommylikehu: yep. maybe we need to merge our specs intro the one. I'll check it
16:16:55 <tommylikehu> ok
16:16:56 <jungleboyj> Ok.  Cool.
16:17:02 <jungleboyj> tommylikehu:  Will you be in Vancouver?
16:17:10 <tommylikehu> no
16:17:19 <tommylikehu> sean will be there
16:17:28 <smcginnis> I plan to be in the placement discussion.
16:17:28 <jungleboyj> e0ne?
16:17:40 <smcginnis> But if there is anything we can work on before then, that would be good.
16:17:40 <e0ne> I hope so
16:17:52 <jungleboyj> e0ne:  Ok. Good.
16:17:55 <jungleboyj> smcginnis:  ++
16:17:59 <e0ne> I should get visa in the end of April
16:18:09 <jungleboyj> Would be good for us to all go into the discussion prepared.
16:18:16 <smcginnis> ++
16:18:24 <e0ne> +1
16:19:08 <jungleboyj> e0ne:  and tommylikehu  Can you guys work on getting the new spec better outlined and we can have a discussion before the forum based on that?
16:19:17 <tommylikehu> sure
16:19:30 <e0ne> jungleboyj: sure, we'll do it
16:19:51 <jungleboyj> #action e0ne and tommylikehu to work on new Placement Service spec .  Team to review and discuss before Vancouver.
16:20:24 <jungleboyj> Ok, that leads nicely into the next topic:
16:20:39 <jungleboyj> #topic Vancouver Forum Topic Proposals
16:20:50 <jungleboyj> #link https://etherpad.openstack.org/p/YVR-cinder-brainstorming
16:20:56 <jungleboyj> So, that is the list we currently have.
16:21:48 <jungleboyj> Does anyone have concerns with me submitting those topics?
16:21:58 <eharney> i'm not attending, so don't list me on the tempest thing
16:22:07 <jungleboyj> eharney:  :-(
16:22:24 <jungleboyj> Do we want to still propose that then?
16:22:43 <smcginnis> eharney: :(
16:22:54 <jungleboyj> @!b
16:22:54 <_pewp_> jungleboyj (╯°□°)╯︵ ┻━┻ ︵ ╯(°□° ╯)
16:22:56 <eharney> i'm skeptical that it's of user interest anyway, but it may be good to talk about it somewhere
16:23:04 <smcginnis> Yeah, wasn't sure on the tempest one in the first place. I think we need to work with some -QA folks to prep for something like that.
16:23:18 <smcginnis> Maybe better as a ML discussion?
16:23:40 <jungleboyj> smcginnis:  ++ or set time for it at the next PTG and see if we can do it cross-project?
16:23:54 <smcginnis> Yeah, that would be good too.
16:24:28 <jungleboyj> jgriffith:  Is going to be there and I think his topics are good.
16:24:42 <jungleboyj> Chris is going to submit the last one.
16:24:48 <jungleboyj> So, I will put the other 4 in.
16:25:18 <jungleboyj> #action jungleboyj to submit 4 topics for the forum in Vancouver.
16:25:45 <jungleboyj> Any other concerns there?
16:25:56 <jungleboyj> Other than :-( over eharney not coming
16:26:34 <jungleboyj> #topic stable/branch policy changes discussion
16:26:43 <jungleboyj> Let the fun begin.
16:26:53 <e0ne> :)
16:27:14 <eharney> i'm a little unsure on what we still need to figure out here
16:27:32 <eharney> but i do get the feeling that everyone hasn't landed in the same place on this yet
16:27:42 <jungleboyj> eharney:  Right.
16:27:52 <eharney> https://review.openstack.org/#/c/557869/  being a good example i was just looking at...
16:28:09 <jungleboyj> smcginnis:  Is it safe to say that the community has moved to keeping branches longer?
16:28:59 <jungleboyj> eharney:  Now, that looks like a feature backport rather than a fix.
16:29:01 <smcginnis> Yep, they will now be kept around.
16:29:02 <jungleboyj> What am I missing?
16:29:29 <eharney> jungleboyj: that making SSL work correctly between Cinder and the backend is not a feature :)
16:29:47 <smcginnis> I wouldn't really consider actually verifying SSL connections to be a feature.
16:30:07 <eharney> especially when we already have an option that says it does that...
16:30:20 <eharney> which just silently fails to work in this case
16:30:49 <jungleboyj> eharney:  Ok, fair enough.  It is addressing a security issue.
16:31:52 <jungleboyj> I will change my vote on that one.
16:32:28 <jungleboyj> So, at this point we will take anything that is appropriate for backport to /stable/queens back to pike and ocata as well?
16:32:46 <eharney> it's about risk vs benefit delivered by the fix
16:33:17 <smcginnis> I think as long as it's fixing an issue that an end user or operator might run in to and it's not a new feature, we should get it backported.
16:33:47 <eharney> right
16:33:48 <jungleboyj> eharney:  Well, you are the one benefitting most from fixes ... so ...
16:33:55 <eharney> well, sorta, but i mean...
16:34:20 <eharney> i just end up backporting them downstream if they don't land in stable anyway, so i do this risk assessment constantly
16:34:49 <smcginnis> eharney: Do you have a set of patches we should get backported upstream so you don't have to carry them downstream?
16:34:55 <eharney> it's more about benefiting deployers who try to use cinder for more than a few months
16:35:10 <jungleboyj> smcginnis:  Good question.
16:35:22 <hemna_> smcginnis, +1
16:35:50 <eharney> well most of them are going to newton etc, which can't be backported or even proposed for backport upstream -- in general we try to push anything we backport downstream toward stable branches as part of the process
16:35:57 <hemna_> eharney, so are you suggesting we allow new features to get backported?
16:36:03 <eharney> no
16:36:10 * e0ne is happy because there is no custom patches in downstream cinder
16:36:17 <hemna_> ok cool :)
16:36:37 <hemna_> so...what's the issue then really?
16:37:02 <e0ne> eharney: we've got the same workflow for our downstream too
16:37:40 <eharney> we've trended toward being very conservative when looking at backports, and to be useful, especially with a longer-lived stable release, we need to make sure we are getting the right fixes in
16:37:41 <jungleboyj> Ok ... So, I think the answer is that we let people backport back to Ocata if it fixes something a user/operator may see.
16:37:53 <eharney> not sure there's a particular issue, just that it's an adjustment from the previous idea of "nothing lands after 6 months"
16:38:13 <eharney> also -- reviewers should be thinking about things like "should this also go to stable" when reviewing patches on master
16:38:14 <jungleboyj> So what do we do with driverfixes/ branches?
16:38:25 <jungleboyj> Do we still do that for n-3 ?
16:38:32 <smcginnis> jungleboyj: I'd say leave the ones that are there, there.
16:38:40 <jungleboyj> smcginnis:  ++
16:38:47 <eharney> keep the current driverfixes branches running... don't make new ones until we have to
16:38:55 <smcginnis> jungleboyj: I plan on going through and proposing things that went into driverfixes/ocata into stable/ocata
16:39:00 <e0ne> eharney: +1
16:39:23 <jungleboyj> smcginnis:  That would be great.  Thank you!
16:39:46 <smcginnis> If we do anything with them, I think we should maybe delete driverfixes/ocata (once patches are merged over to stable) just so there's no confusion between the two since stable/ isn't going away.
16:40:15 <hemna_> +1
16:40:16 <ganso> smcginnis: wouldn't we be re-creating driverfixes/ocata on the next 6 months?
16:40:29 <ganso> smcginnis: as it will be older than 18 months
16:40:44 <smcginnis> ganso: No, we are not deleting them anymore starting with ocata.
16:41:02 <tbarron> it's only driverfixes/ocata that overlaps
16:41:15 <tbarron> if we support stable back to ocata
16:41:16 <jungleboyj> tbarron:  Right.
16:41:23 <smcginnis> tbarron: Yep. The stable policy change starts with ocata, so anything older is already gone.
16:41:33 <smcginnis> And we haven't created newer driverfixes branches.
16:41:40 <jungleboyj> But once we get beyond 18 months we may have to recreate driverfixes/ocata .
16:42:00 <smcginnis> ?
16:42:03 <tbarron> so i'm thinking of moving everything from driverfixes/ocata to stable/ocata
16:42:04 <jungleboyj> Though we would rather not.
16:42:12 <jungleboyj> tbarron:  ++
16:42:27 <smcginnis> tbarron: That's my plan for Cinder, so would be good if Manila did the same.
16:42:44 <hemna_> moving forward driverfixes would only be needed after 18 months out for an older release.
16:42:51 <jungleboyj> smcginnis:  What I am trying to understand is what we do once Ocata goes beyond the 18 month point ...
16:43:00 <jungleboyj> hemna_:  Right
16:43:04 <smcginnis> Nothing
16:43:17 <smcginnis> The stable/ocata branch will not be deleted anymore.
16:43:36 <jungleboyj> smcginnis:  Right, but will we just keep taking patches then?
16:43:37 <smcginnis> It's there, and as long as someone is willing to backport and merge fixes, it's in "extended maintenance"/
16:43:46 <jungleboyj> smcginnis:  Ahhhh.
16:44:07 <smcginnis> It's up to teams how long they want to care about older branches, but there will not be a stable policy enforcing that they must die.
16:44:13 <ganso> so there will be no need for driverfixes branches ever again?
16:44:17 <smcginnis> They'll be allowed a "natural death" :)
16:44:28 <smcginnis> ganso: I don't believe there will be.
16:44:42 <jungleboyj> smcginnis:  I understand now.
16:44:42 <tbarron> smcginnis: yup
16:45:11 <jungleboyj> Ok, so I agree that we should get stable/ocata sync'ed up and then we should get rid of that driverfixes branch.
16:45:12 <hemna_> smcginnis, not even for after 18+ months is up?
16:45:33 <hemna_> 18 months isn't that long for deployments IMHO
16:45:40 <jungleboyj> Eventually *fingers crossed* people will move beyond using that branch.
16:45:49 <tbarron> it's up to teams if / when they want to retire stable branches starting with ocata
16:45:55 <e0ne> hemna_: +1
16:46:00 <smcginnis> It's only after a branch goes into unmaintained state due to no one doing anything with it for an extended period of time that it will go to EOL, but the branch will still be kept around.
16:46:04 <smcginnis> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
16:46:14 <hemna_> tbarron, so we can still push driver fixes for stable/newton ?
16:46:23 <eharney> jungleboyj: sure, eventually... but i think about branches living 5+ years ;)
16:46:34 <tbarron> hemna_: no, "starting with stable/ocata"
16:46:46 <jungleboyj> tbarron:  ++
16:46:49 <hemna_> I guess what I'm asking is, how/where do we push driver fixes for a branch that's > 18 months old.  because we will still have customers that want them.
16:46:52 <jungleboyj> eharney:  You poor devil
16:46:56 <tbarron> hemna_: you'll stiil have driverfixes/newton
16:47:06 <jungleboyj> Right.
16:47:41 <smcginnis> if release <- newton: patch driverfixes; else: patch stable
16:47:43 <tbarron> hemna_: if < ocata, driverfixes; else, stable
16:47:50 <smcginnis> tbarron: Hah
16:47:52 * jungleboyj laughs
16:47:55 <tbarron> smcginnis: has better syntax
16:48:03 <tommylikehu> lol
16:48:08 <jungleboyj> Did you two seriously just do that?
16:48:14 <smcginnis> s/<-/<=/ :)
16:48:32 <tbarron> ternary form now
16:48:35 <hemna_> hehe
16:48:37 * tbarron stops
16:48:42 <jungleboyj> Ok.  So, I think we are all at a point of understanding an agreement.
16:49:34 <smcginnis> We're at least a little less confused. ;)
16:49:42 <e0ne> smcginnis: :)
16:49:46 <jungleboyj> #action for smcginnis is make sure that stable/ocata and driverfixes/ocata are in sync.
16:50:09 <jungleboyj> #action smcginnis or jungleboyj delete driverfixes/ocata once things are sync'ed up.
16:50:09 <smcginnis> Sounds good.
16:50:43 <jungleboyj> #action jungleboyj  Document Cinder's interpretation of extended maintenance for backports.
16:51:27 <Swanson> jungleboyj, got if for you. "If the branch exists then go nuts."
16:51:53 <jungleboyj> Swanson:  :-)
16:52:05 <jungleboyj> Ok, lets move on to the final topic with 9 minutes.
16:52:22 <jungleboyj> #topic ``volume:extend_attached_volume`` policy rule mechanism does not allow backends that do not support this feature to be handled separetely, creating a bad user experience
16:52:27 <jungleboyj> lseki:
16:52:33 <lseki> hi
16:52:45 <lseki> so, there's this feature https://github.com/openstack/cinder/blob/master/cinder/api/openstack/rest_api_version_history.rst#342
16:52:53 <lseki> Add ability to extend 'in-use' volume
16:53:05 <lseki> Administrator can disable this ability by updating the volume:extend_attached_volume policy rule
16:53:09 <jungleboyj> #link https://github.com/openstack/cinder/blob/master/cinder/api/openstack/rest_api_version_history.rst#342
16:53:40 <lseki> if the admin has some backends that support in-use extend, and others that doesn't
16:54:15 <lseki> when he uses a policy rule, it will enable/disable everything
16:54:28 <e0ne> lseki: why don't use capabilities for this?
16:54:42 <lseki> e0ne: that's the idea
16:54:56 <lseki> it could be rather an extra-spec/capability
16:55:04 <tommylikehu> we can ask driver to report this capability then add the extra spec before scheduling to the schedulr
16:55:06 <e0ne> lseki: https://github.com/openstack/cinder/blob/master/cinder/volume/manager.py#L133
16:55:09 <ganso> e0ne: AFAWK there is no way to do that currently, as extra-specs/capabilities for this do not exist
16:55:29 <e0ne> tommylikehu: +1
16:55:55 <ganso> we should make it an official one instead of "extra_capabilities", IMO
16:56:11 <e0ne> IMO, policy shouldn't depend on drivers and backends
16:56:12 <jungleboyj> ganso:  Yeah, kind of sounds that way.
16:56:16 <ganso> as it maps to a feature in the API
16:56:40 <ganso> e0ne: +1, policies shouldn't do this kind of thing
16:57:35 <ganso> so is there agreement that an extra-spec and respective capability should be created to address this?
16:57:38 <tommylikehu> what is the difference if we filter this out in the scheduler or let it failed in the backend
16:58:13 <jungleboyj> 2 minutes.
16:58:36 <jungleboyj> tommylikehu:  If it fails in the scheduler can we get a better error back to the user?
16:59:10 <ganso> if it fails in the backend and there is no way to tell the manager that's because this feature is not supported it would go into extending_error
16:59:22 <jungleboyj> ganso:  Yuck.
16:59:27 <ganso> that would be a not very good user experience IMO, as the backend probably didn't even try to extend the volume
16:59:27 <smcginnis> 1 minute
16:59:54 <jungleboyj> So, it sounds like we have something to fix here.
16:59:58 <ganso> ok we might need to table this discussion
17:00:22 <jungleboyj> lseki:  Can you work with ganso and e0ne to propose a solution?
17:00:40 <jungleboyj> Or we can finish this discussion in channel?
17:01:01 <jungleboyj> Silence.
17:01:03 <lseki> I think this needs further discussion
17:01:12 <lseki> not sure if it's a bug or a feature
17:01:19 <jungleboyj> Ok lets pick this up next week then.
17:01:33 <jungleboyj> Thanks everyone!
17:01:37 <jungleboyj> #endmeeting