16:00:08 <jungleboyj> #startmeeting Cinder
16:00:09 <openstack> Meeting started Wed Apr 18 16:00:08 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:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:12 <openstack> The meeting name has been set to 'cinder'
16:00:15 <erlon> hey
16:00:19 <jungleboyj> Courtesy ping:  jungleboyj DuncanT diablo_rojo, diablo_rojo_phon, rajinir tbarron xyang xyang1 e0ne gouthamr thingee erlon tpsilva patrickeast tommylikehu eharney geguileo smcginnis lhx_ lhx__ aspiers jgriffith moshele hwalsh felipemonteiro lpetrut
16:00:28 <jungleboyj> @!
16:00:29 <_pewp_> jungleboyj ＼( ･_･)
16:00:29 <tommylikehu> hey
16:00:39 <tpsilva> hello
16:00:45 <lseki> hi
16:00:46 <hamdyk> hello
16:00:49 <smcginnis> o/
16:00:56 <e0ne> hi
16:01:09 <ganso> hello
16:01:21 <tbarron> hi
16:01:22 <_alastor_> o/
16:01:41 <xyang> hi
16:02:50 <jungleboyj> Ok, looks like we have a pretty good quorum here.
16:02:54 <eharney> hi
16:03:11 <jungleboyj> eharney:  Good.  Was hoping to see you as well.  :-)
16:03:43 <jungleboyj> Lets get started
16:03:49 <jungleboyj> #topic announcements
16:04:02 <jungleboyj> So, I am planning to cut milestone 1 today.
16:04:19 <jungleboyj> Want to make sure to stay on top of that.
16:04:28 <Swanson> hi
16:05:07 <jungleboyj> Nothing really major to announce with milestone 1 though.  I did get the schedule for Cinder out on the web.
16:05:22 * jungleboyj is such a slacker
16:05:41 <jungleboyj> Just a reminder to watch the mailing list as the TC campaigning has started.
16:05:51 <jungleboyj> Looks like good candidates out there.
16:06:19 <jungleboyj> I have also gotten our Forum topics posted.  So, we will see what comes of that.
16:06:37 <jungleboyj> #link https://etherpad.openstack.org/p/cinder-rocky-meeting-agendas
16:06:49 <jungleboyj> Our agenda for today for everyone's reference.
16:07:04 <jungleboyj> I think that is all we have for announcements.
16:07:20 <jungleboyj> #topic Rocky Priorities Review
16:07:36 <jungleboyj> So, I see that we have gotten through some of the specs and got them merged.  Thank you!
16:07:48 <jungleboyj> I have updated the Rocky Specs/reviews accordingly.
16:08:09 <jungleboyj> Hope as we go toward milestone 2 we will see more reviews show up in here.
16:08:25 <jungleboyj> #link https://etherpad.openstack.org/p/cinder-spec-review-tracking
16:08:29 <jungleboyj> One question.
16:08:54 <jungleboyj> e0ne:  We have the same spec under Generic Backup Implementation as well as Scheduler FIxes/improvements.
16:08:56 <jungleboyj> Is that right?
16:09:45 <jungleboyj> e0ne:  ?
16:10:09 <e0ne> jungleboyj: scheduler improvements will be addressed separately from generic backups
16:10:09 <jungleboyj> Beuler ... Beuler ......
16:10:39 <jungleboyj> Ok, so I thought you were going to push up some changes to the Generic Backup spec based on discussion at the PTG.
16:11:04 <erlon> jungleboyj, that is actually another topic
16:11:20 <jungleboyj> erlon:  That was what I thought.
16:11:22 <e0ne> jungleboyj: I need to speed with geguileo. mayby I messed something
16:11:29 <erlon> the scheduler improvements is already listed on the top
16:11:37 <jungleboyj> erlon:  Right.
16:11:42 <jungleboyj> So, that link in there is wrong.
16:12:10 <e0ne> here is a second spec according to scheduler https://review.openstack.org/#/c/559718/1/specs/rocky/support-placement-api.rst
16:12:12 <jungleboyj> e0ne:  Are you still planning on pushing an update to the Generic Backup Implementation spec?
16:12:33 <e0ne> jungleboyj: I'll ask Gorka and let you know our decision
16:12:42 <jungleboyj> e0ne:  Ok.  Sounds good.
16:13:00 <e0ne> jungleboyj: at least, I need to add something backups via scheduler related things
16:13:24 <jungleboyj> Right.
16:13:51 <jungleboyj> Ok, I won't spend more time on this if you are working on it.
16:13:53 <e0ne> I've got working PoC, so it will be easier now
16:14:01 <jungleboyj> e0ne:  Good.
16:14:33 <jungleboyj> geguileo: Are you here?
16:14:37 <erlon> e0ne, that name of that spec (support placement) is very misleading
16:14:47 <geguileo> jungleboyj: I am
16:14:57 <tommylikehu> erlon:  ok..
16:15:00 <jungleboyj> Hey!  Here is your weekly harassment.
16:15:30 <e0ne> erlon: I agree. We'll have a conversation at the Summit too
16:15:42 <erlon> e0ne, nice
16:15:58 <jungleboyj> geguileo:  Any HA development updates?
16:16:11 <geguileo> nop  :-(
16:16:12 <jungleboyj> e0ne:  Cool.  Please make sure to pull me in on that.
16:16:20 <jungleboyj> geguileo: Ok.
16:17:02 <jungleboyj> #topic HA development progress
16:17:09 <jungleboyj> No updates for this week.
16:17:23 <jungleboyj> #topic Ocata backport from driverfixes progress
16:17:43 <jungleboyj> smcginnis: Thank you for all the work you put in to moving things from driverfixes/ocata to stable/ocata
16:17:53 <jungleboyj> I have gone through and looked at all of those.
16:18:07 <jungleboyj> eharney:  Do you want to look at all of those or should I just merge them so we can move on?
16:18:32 <eharney> i'll pick through some more of them shortly
16:19:08 <jungleboyj> eharney:  Ok, smcginnis was wondering if I should just merge them but I would feel better having you take a look if you can.
16:19:24 <eharney> i think quite a lot of them were already +W'd and just waiting on the beginning of the series to get approved, right?
16:19:25 <smcginnis> There's just a few that haven't been approved yet. All have at least one +2.
16:19:36 <smcginnis> #link https://review.openstack.org/#/q/status:open+project:openstack/cinder+branch:stable/ocata+topic:driverfixes_sync
16:19:46 <eharney> there are only like 5 left, i'll look at them today
16:20:15 <smcginnis> Thanks. It would be good to get driverfixes and stable in sync.
16:20:22 <jungleboyj> smcginnis:  ++
16:20:36 <e0ne> smcginnis: +1
16:20:38 <jungleboyj> eharney:  Thank you!
16:21:10 <jungleboyj> Next topic.
16:21:26 <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:21:35 <jungleboyj> Continued discussion from last week.
16:21:41 <jungleboyj> lseki:  You here?
16:21:45 <lseki> hi
16:22:36 <lseki> we talked about using a extra-spec/capability instead of policy rule
16:22:39 <jungleboyj> So, we didn't come to a conclusion on this last week.
16:22:48 <lseki> so, I'm not sure if it would be a bugfix or a feature
16:23:01 <ganso> as per our discussion last week, it seemed to be considered a bug
16:23:26 <jungleboyj> ganso:  Right.  We didn't properly consider this when the feature was implemented.
16:23:41 <smcginnis> Yep, that's my take of it - it's a bug.
16:23:41 <ganso> but adding a new extra-spec/capability as  a bugfix seems like a possible stretch of a bugfix
16:24:05 <lseki> considering it as a bug, we could backport it to pike/queens
16:24:11 <jungleboyj> :-)
16:24:46 <jungleboyj> Well, before we talk about backporting lets come to agreement as to how we want to resolve it.
16:25:10 <ganso> jungleboyj: I assumed we reached agreement on the extra-spec/capability approach
16:25:41 * erlon miss the old voting balots
16:26:07 <jungleboyj> Ok, so we will need drivers that support extending a volume to report it as a capability ...
16:26:24 <ganso> and the capability should default to False
16:26:35 <Swanson> Wait, what?
16:26:47 <erlon> Swanson, what what?
16:26:59 <jungleboyj> erlon: what what what?
16:27:00 <Swanson> Why false?
16:27:34 <Swanson> Now I have to do work to support something I think I can just do. (He said, not checking.)
16:27:47 <ganso> Swanson: because it is something that backends should explicitly report that they support, rather than assume they do if they do nothing, which could lead to bad user experience
16:27:49 <erlon> Swanson, False so people that supports move that to true, and you dont have driver that does not support reporting true
16:28:13 <jungleboyj> Swanson:  Defaulting to true doesn't really resolve the problem.
16:28:24 <ganso> Swanson: in that case, if you already do, the person implementing this bugfix should add the capability reporting line of code to all drivers that support it
16:28:25 <smcginnis> I think most do support it. True would keep the existing behavior.
16:28:47 <smcginnis> Otherwise if it is working for someone now, then they upgrade, suddenly they need to change config to keep doing what they were doing.
16:28:47 <Swanson> Wouldn't people who don't support it and don't want people using them to have a suck experience wouldn't they change it to false?
16:28:53 <eharney> what is the behavior of the API if the driver doesn't support this?
16:28:57 <jungleboyj> Ok ...
16:29:03 <jungleboyj> Swanson:  True.
16:29:16 <smcginnis> eharney: I believe it would attempt to, fail, and report that back to the user.
16:29:21 <smcginnis> So no real difference here.
16:29:29 <smcginnis> If it's True that is.
16:29:44 <smcginnis> Otherwise, it will just start failing for everyone until they figure out what changed.
16:29:45 <ganso> smcginnis: when they upgrade the new code should already include the new capability being reported for drivers that support it
16:29:47 <eharney> the volume would just revert to in-use, right?
16:30:23 <ganso> smcginnis: it could fail in a bad way if it is not properly handled in the driver
16:30:56 <erlon> eharney, that would only make sense during volume creation, if the volume is already created and the BE does not support, the extra-spec will not be used
16:31:12 <ganso> eharney: in NetApp's case, it remains detached with status "in-use", so it is a broken situation
16:31:34 <ganso> eharney: and would require a ticket to reset the state
16:31:52 <smcginnis> ganso: Wait, this is extending an in-use volume I thought.
16:31:58 <eharney> yeah something isn't adding up here
16:32:04 <ganso> eharney: this is just an example of what could possibly happen. We intend to fix that to prevent that situation regardless of the new implementation we are discussing here
16:32:35 <ganso> smcginnis, eharney: yes our driver currently has a bug in this workflow that detaches while trying to extend while it is attached
16:32:35 <eharney> i thought the whole source of limitations w.r.t. in-use extend was about what nova/the hypervisor supported
16:32:55 <smcginnis> ganso: Well that's a bigger issue then. It should not detach the volume. That's bad.
16:33:02 <smcginnis> eharney: ++
16:33:04 <eharney> smcginnis: right
16:33:04 <ganso> smcginnis: yes, we are going to fix it regardless
16:33:21 <smcginnis> ganso: But that doesn't have anything to do with the current topic.
16:33:27 <smcginnis> ganso: That's just a bug in the netapp driver.
16:33:33 <jungleboyj> smcginnis:  ++
16:33:34 <ganso> smcginnis: but we are talking about the user experience here, of which the user would have already created a volume and finds out cannot be extended because the backend does not support it
16:33:56 <smcginnis> ganso: So the volume stays in the in-use state as you said above.
16:34:02 <ganso> smcginnis: yes, it was just an example of what could happen if we leave the default to True and drivers don't handle this kind of situation
16:34:02 <smcginnis> So what's the bad experience.
16:34:11 <smcginnis> Either the volume fails to extend or it works.
16:34:15 <eharney> there is another approach too
16:34:30 <smcginnis> And why it fails to extend doesn't matter if it's disabled or not supported.
16:34:33 <eharney> we discussed at one point allowing the extend to succeed, but not having it really take effect until a detach/reattach was done later
16:34:43 <ganso> smcginnis: defaulting to False avoids that for drivers that do not handle it
16:34:59 <smcginnis> And f's all the other's that do and changes existing nbehavior.
16:35:15 <Swanson> My point.
16:35:17 <ganso> smcginnis: actually no, because it will never ask the driver to extend the volume online as it will not be supported, since it would default to False
16:35:40 <smcginnis> And it won't ask the drivers that do support it either becuase it would default to False from what you are saying though.
16:35:54 <jungleboyj> ganso:  But doesn't that appear the same to the end user.
16:36:09 <ganso> smcginnis: sorry I didn't get your last message ^
16:36:18 <ganso> smcginnis: s/get/understand
16:36:22 <smcginnis> I don't care about drivers that don't support it. It's a basic storage operation to extend a volume. If you're storage fails, get new storage.
16:36:41 <smcginnis> We shouldn't hobble all the storage that does work for the few that don't.
16:37:02 <jungleboyj> Agreed.
16:37:34 <ganso> smcginnis: well I don't really see a problem with that, it could go either way, my suggestion was to False, and find the ones that should report True. The opposite works too.
16:37:58 <jungleboyj> So, if we add the capability, we default to true.  Then users who have an environment that have a combination of storage that does or doesn't support it can use the extra spec and make sure they don't schedule to that storage if they need the capability.
16:38:16 <smcginnis> jungleboyj: ++
16:38:17 <ganso> jungleboyj: +1
16:38:18 <jungleboyj> If the storage provider doesn't update their capabilities ... well, tough.
16:38:27 <eharney> it sounds like it might make more sense to add a capability that says that this is not supported
16:38:31 <eharney> if it's really a rare situation
16:38:40 <eharney> then by default everything just does what it should
16:38:43 <jungleboyj> eharney:  Hmmm.
16:38:53 <ganso> jungleboyj: since I know my storage does not support it, I'll make sure to update my capabilities. I can't speak for others though. They might face bugs and it will be their problem then
16:39:40 <eharney> otherwise we make the majority of deployers worry about a capability for no reason
16:40:13 <jungleboyj> ganso: smcginnis erlon  Thoughts on eharney  proposal?
16:40:14 <ganso> eharney: do we know if the majority of drivers support it?
16:40:38 <eharney> ganso: i'm not sure, but my guess is that most do... was hoping someone here knows :)
16:41:01 <erlon> jungleboyj, I prefer this approach, defaults goes True, and we report false
16:41:13 <smcginnis> eharney: Isn't that proposal basically the same as defaulting it to true and having drivers report false if they do not?
16:41:36 <gman-tx> seems like it
16:41:36 <ganso> smcginnis: only if the majority supports. Otherwise default to False. That's what eharney implied
16:42:01 <jungleboyj> Do we have other capabilities that report an in-ability
16:42:07 <jungleboyj> That is my only concern there.
16:42:37 <eharney> smcginnis: maybe
16:42:55 <erlon> jungleboyj, there may be, dont remember any on top of my head now
16:43:02 <eharney> i'm not sure it's a great idea
16:43:12 <jungleboyj> Ok.  Lets not spend more time on this.  Lets add the capability and default to true.
16:43:20 <jungleboyj> I think that is consistent with what we do elsewhere.
16:43:44 <erlon> eharney, the default value or the hole idea?
16:43:59 <eharney> i'm still not sure why we want to add a driver capability for something that isn't mostly about the driver... but ok
16:44:12 <ganso> erlon: hole idea :P
16:44:14 <erlon> s/hole/whole
16:44:21 <jungleboyj> ganso:  He he he.
16:44:24 <erlon> hahaha
16:44:33 <jungleboyj> eharney:  This is where you flip a table
16:44:48 <smcginnis> eharney: I think in this case it is about the driver. At least one specific one for storage that doesn't support extending volumes.
16:44:51 <eharney> a capability is also not going to work for anyone who has multiple different compute hypervisors
16:45:03 <ganso> smcginnis: +1
16:45:03 <eharney> smcginnis: in the case we are talking about today yes... but i don't think it was when we designed this
16:46:08 <ganso> alright. About backporting... Anything against it?
16:46:25 <jungleboyj> Don't think so.  It is a bug fix.
16:46:30 <jungleboyj> smcginnis:  ^^^ ?
16:46:45 <smcginnis> I want to see the fix first. :)
16:46:57 <jungleboyj> smcginnis:  ++  Makes sense.
16:47:03 <ganso> alright
16:47:08 <jungleboyj> Lets push up the proposed fix, we can review and move on.
16:47:09 <ganso> lseki: did we address all your concerns?
16:47:20 <lseki> ganso: yep
16:47:25 <ganso> =)
16:47:36 <jungleboyj> lseki:  Like the cat that comes in and starts a fight between the dogs and then watches.  :-)
16:47:44 <ganso> ROFL
16:47:46 <eharney> so what about people who actually are using the policy?
16:47:58 <lseki> jungleboyj: hahahahah
16:48:01 <eharney> that still works too?
16:48:24 <ganso> eharney: it should continue to work, but I'd suggest to remove the policy, or at least deprecate it
16:48:33 <ganso> eharney: as the capability will be handling it
16:48:41 <Swanson> Policy is policy, driver support is another thing?
16:48:53 <eharney> ... if they went and configured volume types etc, it's not going to just handle it on upgrade out of the box
16:49:02 <tommylikehu> Swanson: +1
16:49:05 <ganso> perhaps I missed some context when this was originally implemented. What was the purpose of this policy?
16:49:25 <ganso> eharney: even if it defaults to True?
16:49:54 <jungleboyj> Can we move on from this as we have two other topics.  We can come back if time allows otherwise lets handle it through the code review.
16:49:57 <gouthamr> policy prevents users from using the API
16:50:16 <ganso> jungleboyj: ok
16:50:22 <jungleboyj> ganso:  Thanks.
16:50:37 <eharney> api policy changes combined with new capabilities sound like something more appropriate for spec review than code review to me
16:51:12 <erlon> eharney, and therefore it goes out of the scope of a bug
16:51:13 <erlon> :)
16:51:26 <jungleboyj> Oy ... Moving on ...
16:51:35 <jungleboyj> #topic How to name volume type's reserved extra spec key or what's our naming schema for this purpose.
16:51:40 <jungleboyj> tommylikehu:  ^^^^
16:51:47 <tommylikehu> yeah!
16:51:56 <tommylikehu> we have decided to use reserved extra specs to address availability-zone volume type feature during ptg. but we havn't decided what exactly naming rules for the reserved keys.
16:52:09 <eharney> my input is the naming should not be "os-extended:"
16:52:24 <eharney> because that's basically a random string as far as extra specs go
16:52:25 <tommylikehu> yeah. that's what I use in my code patch:)
16:54:00 <jungleboyj> Yeah, that means nothing to me.
16:54:15 <eharney> worse than nothing, it means "api extension" to me... which it's... not
16:54:37 <jungleboyj> eharney:  So any idea what would be better?
16:54:40 <tommylikehu> eharney:  what's your suggestion?
16:54:56 <tommylikehu> os-reseved:xxx?
16:55:10 <eharney> what are these again?  keys that have a special meaning within cinder?
16:55:31 <tommylikehu> yeah, that's what I thought
16:55:42 <jungleboyj> cinder-spec:
16:55:49 <eharney> you wrote it, i'm just asking for clarity :)
16:56:11 <tommylikehu> it means it's a reserved key for cinder
16:56:37 <jungleboyj> cinder-key: or reserved-key:
16:57:08 <tommylikehu> jungleboyj:  both works for me
16:57:12 <eharney> how is it being "reserved" here different from something like a key used to control, for example, replication?
16:57:35 <eharney> i.e. we already have a number of keys like this, right?
16:57:51 <jungleboyj> 3 minutes left
16:58:11 <tommylikehu> cause it's different, we use this in the extra spec, but it will not be used when performing capability filtering as others do
16:58:34 <jungleboyj> Yeah that was how I thought this was different.
16:58:46 <jungleboyj> Not an extra spec for the driver.
16:59:02 <eharney> will there be other cases of needing keys like this in the future?
16:59:15 <jungleboyj> eharney:  Possibly.
16:59:19 <tommylikehu> it could be
16:59:37 <jungleboyj> Lets finish this in the review now that people are aware of it.
16:59:46 <smcginnis> I thought there were some other reserved keys like this.
17:00:06 <tommylikehu> smcginnis:  which are in the format of prefix: name?
17:00:09 <eharney> smcginnis: me too... it's hard to name the field before we come up with a solid definition of what it means...
17:00:29 <eharney> don't call it "os-" anything please
17:00:36 <tommylikehu> lol
17:00:41 <jungleboyj> tommylikehu: eharney smcginnis  Can we finish this in the review?
17:00:41 <smcginnis> tommylikehu: Not sure, but I thought there was something already implemented. Been a very long time since I've looked at that code.
17:00:47 <jungleboyj> eharney:  I agree.
17:00:49 <smcginnis> Guess we'll have to.
17:00:54 <tommylikehu> ok
17:00:55 <jungleboyj> Last
17:01:01 <jungleboyj> #topic Push to merge NVMeOF cinder changes
17:01:09 <jungleboyj> I think this is just a request to look at the reviews.
17:01:11 <ganso> time check
17:01:15 <Swanson> Overtime!
17:01:16 <erlon> -1m
17:01:17 <jungleboyj> hamdyk:  Correct?
17:01:21 <hamdyk> Hi everyone
17:01:35 <hamdyk> jungleboyj: yes
17:01:35 <lseki> hamdyk: hi
17:01:36 <ganso> hamdyk: welcome
17:01:42 <hamdyk> thanks
17:01:42 <Swanson> smcginnis never ran over time.
17:01:44 <jungleboyj> Ok.  We will take a look.
17:01:52 <jungleboyj> And that is the meeting.
17:01:53 <smcginnis> Swanson: Hah!
17:02:01 <jungleboyj> Swanson:  :-p
17:02:04 <hamdyk> can you take a look at the patches and merge thim
17:02:09 <jungleboyj> hamdyk:  Will do.
17:02:12 <hamdyk> I think we in a good shape there
17:02:17 <jungleboyj> Thanks everyone!
17:02:22 <erlon> -2m
17:02:23 <jungleboyj> #endmeeting