16:00:01 <smcginnis> #startmeeting Cinder
16:00:01 <openstack> Meeting started Wed Oct 12 16:00:01 2016 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:05 <openstack> The meeting name has been set to 'cinder'
16:00:06 <smcginnis> Ping-
16:00:07 <smcginnis> dulek duncant eharney geguileo winston-d e0ne jungleboyj jgriffith thingee smcginnis hemna xyang1 tbarron scottda erlon rhedlind jbernard _alastor_ bluex patrickeast dongwenjuan JaniceLee cFouts Thelo vivekd adrianofr mtanino yuriy_n17 karlamrhein diablo_rojo jay.xu jgregor baumann rajinir wilson-l reduxio wanghao thrawn01 chris_morrell stevemar watanabe.isao,tommylike.hu mdovgal
16:00:10 <thingee> o/
16:00:15 <e0ne> hi
16:00:16 <dulek> o/
16:00:18 <mtanino> hi
16:00:22 <geguileo> Hi!
16:00:23 <xyang1> hi
16:00:31 <jgregor> Hello!
16:00:33 <DuncanT> Hi
16:00:46 <Swanson> hello
16:00:49 <patrickeast> Hi
16:00:57 <scottda> hi
16:01:00 <slayer> Hi!
16:01:06 <_alastor1> o/
16:01:22 <smcginnis> #topic Announcements
16:01:41 <jungleboyj> Hello!
16:01:43 <bswartz_> .o/
16:01:48 <smcginnis> I've added all topics from the summit planning etherpad to the schedule.
16:01:59 <smcginnis> All sessions are also added with etherpads here:
16:02:07 <smcginnis> #link https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Cinder Design Summit sessions
16:02:12 <flip214> hi
16:02:34 <smcginnis> If you are leading any of those discussions, please start adding info there to prepare.
16:02:48 <e0ne> ok, will do
16:03:02 <smcginnis> Any extra topics can also be added to our contributor meetup etherpad:
16:03:11 <smcginnis> #link https://etherpad.openstack.org/p/ocata-cinder-summit-meetup Contributor Meetup Etherpad
16:03:33 <smcginnis> Just the afternoon on Friday, but we will handle that like the midcycle and just work our way through topics.
16:04:07 <smcginnis> #topic Documentation needs
16:04:13 <smcginnis> So... documentation.
16:04:25 <smcginnis> Apparently I misunderstood what was being proposed in the past, or things have changed.
16:04:56 <smcginnis> But just so everyone knows, for any patch that has DocImpact in the commit a bug is automatically created against Cinder when that patch merges.
16:05:32 <smcginnis> It is up to us (ideally the person submitting the patch) to take that and follow through with adding anything needed to the config guides or other documentation affected.
16:05:55 <smcginnis> But looking through, I think we are misusing that tag in some cases.
16:06:05 <smcginnis> The general understanding was any config option change required it.
16:06:10 <smcginnis> But that is not always the case.
16:06:26 <smcginnis> Only if additional information needs to be added to go with the config option.
16:06:44 <smcginnis> Otherwise the config options are automatically generated in tables when the docs are built.
16:07:06 <smcginnis> So if having it listed in the table is sufficient, no need to put a DocImpact flag in there.
16:07:29 <geguileo> Good to know
16:07:42 <smcginnis> Any questions/concerns? Or did everyone go to get coffee?
16:08:02 <scottda> smcginnis: I answered your question in the ML about generating help based on microversion.
16:08:06 <scottda> smcginnis: Did you see that?
16:08:16 <smcginnis> scottda: Oh, great. No, not yet.
16:08:23 <scottda> smcginnis: And how that affects generation of the docs
16:08:37 <DuncanT> Is it worth requiring the doc patch to be at least up in draft before we merge, for complex features?
16:08:37 <smcginnis> scottda: I'll take a look after the meeting. Thanks!
16:09:21 <smcginnis> DuncanT: I'd hesitate to make that a hard requirement, but especially for complex features that might be a good pattern to follow.
16:09:50 <smcginnis> We also have the api-ref in-tree now.
16:09:55 <DuncanT> Not as a hard requirement, they usually end up painful, but as a suggestion where it feels necessary
16:10:09 <smcginnis> We really should start to enforce including api doc updates along with the api changes themselves.
16:10:12 <jungleboyj> DuncanT: ++
16:10:19 <smcginnis> DuncanT: +1
16:10:25 <e0ne> smcginnis: +1
16:10:43 <bardia> smcginnis: +1
16:10:55 <xyang2> any reviewers for the groups api doc? https://review.openstack.org/#/c/370526/
16:10:57 <smcginnis> There's also some talk of moving all docs in tree. I'm a little concerned about that, but something to consider.
16:10:59 <diablo_rojo> smcginnis +1
16:11:20 <smcginnis> Then all patches that have a documentation impact can include those updates along with the change.
16:11:55 <smcginnis> I really don't like the idea of cramming more non-functional stuff into the repo, but there definitely are some benefits to that approach.
16:12:04 <smcginnis> Not something I'm going to advocate for any time soon though.
16:13:16 <smcginnis> I'll move on, but ping me in channel if you have any docimpact questions. I can at least try to answer.
16:13:29 <smcginnis> #topic Deprecating various extensions, specifically qos-specs
16:13:32 <smcginnis> thingee: Hey
16:13:38 <thingee> o/
16:14:03 <thingee> hey so I talked about deprecating qos-specs in favor of just using volume type specs
16:14:03 <thingee> xyang2 mentioned something about three releases for deprecating tables?
16:14:22 <xyang2> do we have winston here?
16:14:52 <xyang2> thingee: before talking about the deprecation I'd like to get winston's input as he implemented it
16:14:52 <DuncanT> thingee: I wasn't around for that discussion, what is the justification? There's already a *lot* of stuff in volume type specs
16:15:18 <jgriffith> DuncanT: because that's where it belongs and what it does anyway :)
16:15:19 <xyang2> I found these two original patches by winston: https://review.openstack.org/#/c/29737/, https://review.openstack.org/#/c/42521/
16:15:22 <thingee> but it would still be fine for me to just remove qos_specs_manage from contrib and give a warning if it's loaded in cinder.api.extensions?
16:15:50 <jgriffith> DuncanT: so in all seriousness, the justification was that there tends to be some confusion on "which" method should be used
16:16:05 <smcginnis> thingee: I would think that would be OK.
16:16:13 <DuncanT> jgriffith: Is throwing everything into one pot really helping make things even slightly usable / understandable?
16:16:21 <xyang2> you can't just remove it
16:16:22 <thingee> and I can leave the table around with some migration script to volume type specs.
16:16:30 <xyang2> there are drivers that have implemented it
16:16:38 <smcginnis> DuncanT: To turn it around, why does that need its own api?
16:16:44 <xyang2> some drivers will be broken if you just remove them
16:16:47 <jgriffith> DuncanT: we can chat on the side if it distracts the conversation but yes IMO optional things like that are better in one place rather than 2
16:17:02 <smcginnis> xyang2: I think after 1 cycle being marked deprecated.
16:17:27 <xyang2> I'd like to get winston's comments on this
16:17:44 <dulek> thingee: Yup, we should do it in a way guaranteeing backward compatibility, but it's possible to move that into another table quite quickly (only c-api can modify QoS specs, right?).
16:17:46 <smcginnis> xyang2: Yeah, that would be good to get his input.
16:17:55 <jgriffith> xyang2: yeah, that would be good.  I do remember that part of the reasoning was to be able to modify the qos without retyping the volume
16:17:56 <DuncanT> I'd really like to defer this decision until after spain, I'm not sure IRC has enough bandwidth to actually get a decent discussion
16:18:11 <jgriffith> xyang2: but that doesn't really work that way either
16:18:19 <smcginnis> DuncanT: +1 That makes sense.
16:18:19 <thingee> ok so I'll throw the warning in the file itself to stop using it and instruction to use the migration script and use volume type specs.
16:18:19 <thingee> ok with that aside, I wanted to talk about the other stuff in contrib
16:18:19 <thingee> is there anything in there that really needs to be an extension?
16:18:24 <thingee> whoa serious lag
16:18:28 * thingee catches up
16:18:31 <DuncanT> jgriffith: It was also so the you didn't have to specify the whole of the QoS details for every type
16:18:40 <xyang2> jgriffith: there's a front end and backend
16:18:54 <thingee> dulek: I doubt there are that many to move over, really. lets be realistic
16:18:56 <jgriffith> xyang2: yes, I'm aware
16:19:00 <xyang2> jgriffith: in nova, there is qos specs which is front end
16:19:09 <scottda> thingee: We'd discussed moving things from contrib -> core if they are supported by all drivers.
16:19:22 <scottda> thingee: But maybe not things like consistency_groups
16:19:37 <thingee> scottda: ok good to know, so there are quite a bit of things that I can move over.
16:19:38 <scottda> Or replication?
16:19:49 <dulek> thingee: Sure, I'll be happy to help work out the DB migration strategy if we want that.
16:19:53 <jgriffith> scottda: thingee I'd like to talk about changing that whole structure we have altogether if we could
16:19:54 <xyang2> scottda: no need to move consistency groups.  we will migrate them to groups any way.  actually part of CG is already in v3
16:20:12 <jgriffith> I think we're doing it wrong and should fix it sooner rather than later
16:20:55 <thingee> smcginnis: ok I think I have the information I need, thanks
16:21:07 <jgriffith> LOL
16:21:08 <jgriffith> ok
16:21:11 <xyang2> smcginnis: I mean if we make a decision to get rid of it, we need to make sure all drivers change the implementation to use volume types instead.  we need to give driver maintainers development time
16:21:26 <smcginnis> xyang2: Oh, right. Definitely.
16:21:31 <scottda> jgriffith: you mean this? https://bugs.launchpad.net/cinder/+bug/1627921
16:21:31 <openstack> Launchpad bug 1627921 in Cinder "clean up API versions" [Undecided,Confirmed]
16:21:32 <jgriffith> xyang2: I think we've tabled that and moved on to the contrib discussion
16:21:38 <smcginnis> thingee: Thanks!
16:21:40 <thingee> xyang2: I don't think there are too many. happy to do it myself
16:21:51 <jgriffith> scottda: yes
16:22:04 <xyang2> thingee: it needs code change in the driver, not just removing it
16:22:14 <jgriffith> scottda: so as someobody that's been writing things to consume our API's lately I think we have some room for improvement
16:22:17 <smcginnis> This is probably one of those things we should at least have a quick discussion on Friday afternoon for.
16:22:22 <xyang2> thingee: the keys need to be changed
16:22:31 <thingee> xyang2: not sure you're reading what I said. I said I would change the drivers myself
16:22:31 <thingee> it's not that complicated and not too many instances as you're making it out to be
16:22:40 <scottda> jgriffith: That sounds  good to me at first pass.
16:22:43 <xyang2> thingee: once they are moved to volume types, I think they need to be scoped, etc
16:23:02 <xyang2> thingee: I think that is a change that need to be validated by the storage backend
16:23:07 <jgriffith> scottda: ok, I guess at this point you and I should just talk about it in Barcelona maybe?
16:23:26 <jgriffith> scottda: not like I'm going to work on it between now and then
16:23:48 <scottda> jgriffith: I reckon so. It's probably going to take until P release anyway.
16:23:56 <jgriffith> scottda: no way!
16:24:01 <smcginnis> #topic Open discussion
16:24:02 <jgriffith> O-3 targetted
16:24:29 <smcginnis> We have a cross project session related to proprietary libs and things.
16:24:33 <xyang2> thingee: also documentation has instructions on using qos specs
16:24:40 <xyang2> thingee: driver doc
16:24:44 <smcginnis> I've updated the etherpad we started with what I could find here:
16:24:50 <smcginnis> https://etherpad.openstack.org/p/cinder-brick-driver-externals
16:25:06 <smcginnis> External libs are left highlighted.
16:25:18 <smcginnis> Please take a look and see if I missed anything that you are aware of.
16:25:45 <diablo_rojo> smcginnis, I have talking to other CP Liaisons and we should have decent representation from other projects there
16:25:51 <smcginnis> #link https://etherpad.openstack.org/p/cinder-brick-driver-externals Proprietary lib info
16:26:11 <smcginnis> diablo_rojo: Great! I think it will be a good discussion if we have a good mix there.
16:26:43 <diablo_rojo> smcginnis yeah I have ironic, Manila, and Nova for sure.
16:27:04 <xyang2> thingee: for example, this doc explains in detail how to use qos specs for the VMAX driver: http://docs.openstack.org/newton/config-reference/block-storage/drivers/emc-vmax-driver.html
16:27:43 <smcginnis> Oh, any objection to skipping next weeks meeting? I'll be in Barcelona already, and I know travel will be starting for some others as well.
16:28:16 <jungleboyj> smcginnis: That is good for me.
16:28:24 <bardia> smcginnis: +1
16:28:24 <xyang2> diablo_rojo: that session has the latest Tuesday afternoon spot
16:28:28 <smcginnis> I can wait until Monday or Tuesday and see if any important topics come too, if that helps.
16:28:35 <smcginnis> jungleboyj, bardia: Cool, thanks.
16:28:55 <thingee> xyang2: it sure does
16:28:58 <xyang2> diablo_rojo: overlapping with booth crawl
16:28:59 <smcginnis> I'll wait to send out something to the ML until early next week just in case anything important does come up.
16:29:10 <diablo_rojo> xyang2, Oh noes.
16:29:18 <smcginnis> diablo_rojo: dang it!
16:29:24 <xyang2> I think booth crawl is 5-7
16:29:28 <jungleboyj> Nooooo!!!!
16:29:32 <smcginnis> No official party this year either I hear.
16:29:36 <diablo_rojo> You are correct.
16:30:00 <jungleboyj> So no evening events?
16:30:10 <dulek> jungleboyj: We'll do a Cinder one I guess. ;)
16:30:15 <xyang2> smcginnis: saving money?
16:30:16 <smcginnis> I'm sure there's going to be smaller ones.
16:30:18 <jungleboyj> dulek: ++
16:30:22 <smcginnis> dulek: +A
16:30:28 <DuncanT> Time to go find the next big thing that people are throwing money at....
16:30:36 <smcginnis> xyang2: I guess so.
16:30:37 <jungleboyj> DuncanT: :-(
16:30:40 <smcginnis> DuncanT: ;)
16:30:43 <dulek> DuncanT: :D
16:30:46 <diablo_rojo> DuncanT :)
16:31:03 <jungleboyj> Well kids ... it's been fun.  ;-)
16:31:05 <smcginnis> Tentatively, Cinder meetup Tuesday evening?
16:31:23 <scottda> DuncanT: For parties maybe you should be a wedding planner?
16:31:52 <smcginnis> scottda: And dance instructor. :)
16:31:53 <jungleboyj> smcginnis: And Wednesday night and Thursday night and ...
16:31:59 <smcginnis> jungleboyj: Sold
16:32:35 <scottda> Don't we know someone in Spain that might help with social planning?
16:32:48 <smcginnis> scottda: ;)
16:32:58 <smcginnis> OK, anything else meeting worthy?
16:33:08 <smcginnis> Or can I go get some lunch? :)
16:33:30 <smcginnis> OK, thanks everyone!
16:33:42 <smcginnis> #endmeeting