16:00:19 <smcginnis> #startmeeting Cinder
16:00:20 <openstack> Meeting started Wed Sep 30 16:00:19 2015 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:24 <openstack> The meeting name has been set to 'cinder'
16:00:27 <thingee> o/
16:00:31 <rajinir> howdy
16:00:33 <jgregor> Hello!
16:00:35 <geguileo> Hi!
16:00:35 <rhedlind> hi
16:00:36 <Swanson> Hello
16:00:37 <eharney> hi
16:00:37 <cebruns> Hi
16:00:37 <xyang> hi
16:00:37 <smcginnis> scottda: Very funny.
16:00:40 <jgriffith> o/
16:00:47 <scottda> Hi
16:00:53 <smcginnis> Welcome
16:00:55 <diablo_rojo> hi :)
16:01:04 <smcginnis> #topic Announcements
16:01:10 <jungleboyj> o/
16:01:14 <smcginnis> Not much from my end yet.
16:01:16 <hemna> flerm
16:01:21 <thingee> I have something
16:01:22 <e0ne> hi
16:01:25 <smcginnis> thingee: Do you have any Liberty business to discuss?
16:01:26 <tbarron> hi
16:01:27 <ameade> hi
16:01:28 <jungleboyj> flubber
16:01:32 <smcginnis> thingee: OK, all yours.
16:01:39 <thingee> the base deprecation policy has been accepted
16:01:40 <kmartin> o/, congrats smcginnis, with your new found power
16:01:40 <thingee> http://lists.openstack.org/pipermail/openstack-dev/2015-September/075608.html
16:01:48 <smcginnis> kmartin: Thanks
16:01:53 <mriedem1> o/
16:02:05 <thingee> in Cinder we should keep such things in mind for obtaining the tag
16:02:11 * hemna listens for darth vader breathing sounds.......
16:02:20 <hemna> :P
16:02:27 <smcginnis> :)
16:02:45 <smcginnis> thingee: Thanks. Anything else?
16:03:15 <thingee> if anyone is not familiar with the base deprecation policy, feel free to read the foot notes from the dev list on the weekly newsletter http://www.openstack.org/blog/2015/09/openstack-community-weekly-newsletter-sept-12-18/
16:03:34 <smcginnis> thingee: Liking that devlist summary.
16:03:41 <thingee> that's it
16:03:48 <smcginnis> thingee: Thanks.
16:03:52 <smcginnis> I guess I do have a couple things.
16:04:20 <smcginnis> For any third party drivers, if you did not see there's this:
16:04:21 <smcginnis> http://lists.openstack.org/pipermail/openstack-dev/2015-September/075532.html
16:04:39 <smcginnis> We are following things for the most part, but worth reading through that thread.
16:05:18 <smcginnis> And one final announcement - for now at least - if you are going to be contributing a new driver...
16:05:34 <erlon> hi
16:05:42 <smcginnis> Assume for now that we are following the existing deadlines of needing a new driver my M1.
16:05:56 <thingee> smcginnis: I've worked briefly with hogepodge on the def core stuff here... he's done most of the work of course, but if anyone has questions they can ping me too
16:06:01 <hemna> smcginnis, which includes CI reporting right ?
16:06:02 <smcginnis> This is being discussed, but until we come to some other decisions you should follow what has been set.
16:06:10 <jungleboyj> smcginnis: We are all in agreement that the CI testing we are currently doing meets the needs discussed there?
16:06:13 <hogepodge> o/
16:06:17 <smcginnis> hemna: Yes!
16:06:21 <hemna> :)
16:06:31 <smcginnis> jungleboyj: That is my understanding.
16:06:39 <jungleboyj> smcginnis: Thank you.
16:06:41 * thingee is replying to the milestone-1 driver deadline thread now
16:06:45 <thingee> smcginnis: ^
16:06:50 <smcginnis> And definitely no change in needing CI for new drivers.
16:06:56 <smcginnis> thingee: Will watch for it.
16:07:05 <hemna> yup, just wanted to make it obvious and clear.  thanks
16:07:14 <smcginnis> hemna: Yeah, good call.
16:07:37 <smcginnis> #topic API race patch series
16:07:39 <hogepodge> I'm happy to answer any questions you have. We want to work with your standards and use them to support good vendor behavior.
16:07:45 <smcginnis> jgriffith: You're up.
16:07:49 <jgriffith> thanks
16:07:53 <smcginnis> hogepodge: Thanks!
16:08:06 <smcginnis> geguileo: Courtesy ping as well.
16:08:11 <jgriffith> Ok, so first off I want should be clear that I think this is great work
16:08:15 <geguileo> smcginnis: thanks :-)
16:08:43 <jgriffith> My concern is only being better organized in how it's done and making sure people are actually clear on how these patches work
16:09:03 <geguileo> jgriffith: I have updated the specs
16:09:11 <jgriffith> I also have difficulty with dependency chains once they are greater than 3 or 4
16:09:19 <jgriffith> 8 is def hard for me to keep up with
16:09:21 <geguileo> they should be more clear on what it's been done and why
16:09:26 <jgriffith> geguileo: thanks!!  I'll look at it
16:09:49 <jgriffith> If I'm the only one that has these concerns I'll happily remove my down vote and we can get on with it
16:09:58 <hemna> sounds good
16:10:01 <geguileo> It wasn't supposed to get that many dependencies, but it grew
16:10:16 <jgriffith> geguileo: hehe.. yeah, that happens :(
16:10:20 <geguileo> jgriffith: Other people had concerns in the sense that it wasn't clear
16:10:20 <dulek> Well we can either have a chain or unreviewable patches.
16:10:29 <dulek> Both approaches are bad.
16:10:33 <jgriffith> dulek: I disagree with your statement 100%
16:10:42 <geguileo> That's why they asked me to write better specs
16:10:44 <jgriffith> dulek: IMO there's a balacne
16:10:51 <hemna> jgriffith, so fwiw, I was a bit confused on some of the while loops, and was hoping to get some clarity in comments on some of those.
16:11:04 <geguileo> jgriffith: I can split the dependencies
16:11:06 <hemna> but I raised that with geguileo already and should be cool w/ updated patches
16:11:08 <smcginnis> I do think it's a clear sign it needs to be well documented and communicated when it grows to that point.
16:11:11 * DuncanT is also not convinced that the entire patch series is the right way forward. I really like the first patch in the series though
16:11:11 <jgriffith> hemna: yeah...
16:11:22 <geguileo> jgriffith: But then it makes it harder for me to check tempest in my env with all patches applied simultaneously
16:11:24 <jgriffith> So I guess my question is, "are these concerns just me"?
16:11:32 <jgriffith> obviously dulek is good with it... how about others?
16:11:41 <smcginnis> jgriffith: I agree with you.
16:11:43 <jgriffith> Like I said, if it's just me I'll move along
16:12:10 <geguileo> So the concern is that it's not clear why I'm doing those loops in the patches
16:12:12 <hemna> I'm ok with it, just wanted some clarifications on how the compare/swap db.conditional_update loops exit
16:12:14 <geguileo> Or is it something else?
16:12:28 <hemna> it just wasn't clear to me that it doesn't deadlock
16:12:35 <geguileo> hemna: I tried to explain it in the specs, if it's not clear I'm improve it
16:12:35 <jgriffith> One other thing.... geguileo are you going to be in Tokyo?
16:12:40 <dulek> hemna: I think that's explained in the spec now.
16:12:45 <geguileo> jgriffith: Yes
16:13:08 <jgriffith> Maybe something of this magnitude deserves a discussion at the summit before we take it on?
16:13:10 <xyang> hemna: you are working on removing locks, right?  That is also related to geguileo's work?
16:13:18 <smcginnis> jgriffith: +1
16:13:22 <smcginnis> https://etherpad.openstack.org/p/cinder-mitaka-summit-topics
16:13:25 <hemna> jgriffith, as a side note, this effort seems to be intertwined, if not a replacement for the remove volume locks spec that I've been updating.
16:13:26 <jgriffith> There are folks that think this may not be a needed direction, but they appear to not have voices or keyboards :)
16:13:38 <geguileo> jgriffith: You mean of the magnitude of removing API races?
16:13:45 <hemna> I want to make sure we are on the same page
16:13:46 <jgriffith> hemna: yeah.. so what are you proposing?
16:14:01 <hemna> well, the removal spec was out I think before the compare/swap stuff
16:14:05 <jgriffith> geguileo: yes... more accurately the magnitude of your patch set
16:14:14 <hemna> but I'm confused if his patches will already fix what we are trying to achieve
16:14:22 <jgriffith> and as thingee pointed out on the ML there are other things in OpenStack going on like the hashring idea
16:14:24 <geguileo> jgriffith: Well, we have api races everywhere, so they all have to be removed
16:14:35 <hemna> geguileo, +1
16:14:38 <jgriffith> which I spent some time looking at the other night and it's kinda slick
16:14:40 <geguileo> jgriffith: That's why I tried to only update a couple of methods on each patch
16:14:41 <dulek> hemna: The patches won't do that. geguileo doesn't change any API behavior.
16:15:18 <jgriffith> geguileo: so one suggestion is focus on an api call at a time maybe?  Rather than a huge dependency chain?
16:15:19 <thingee> jgriffith: http://lists.openstack.org/pipermail/openstack-dev/2015-July/071072.html
16:15:23 <jgriffith> thingee: thanks!
16:15:25 <thingee> for reference of the hashring ml post
16:15:26 <hemna> dulek, true, but as jgriffith pointed out in the removal spec, the delete volume case seems to be already covered, because it already checks valid states.
16:15:29 <hemna> it's just confusing
16:15:41 <geguileo> jgriffith: Each patch focusses on one or two calls only
16:15:42 <DuncanT> jgriffith: I'm not understanding how the hash ring gives race free A/A... If it can, I'd like somebody to explain it slowly and possibly repeatedly until I get the point
16:16:03 <geguileo> jgriffith: That's why there are so many and there will be a lot more
16:16:03 <dulek> hemna: I'll rethink that and reach you offline.
16:16:05 <jgriffith> DuncanT: it's basically a lock mechanism
16:16:16 <hemna> at this point, it might be beneficial to have a google hangout to hash some of this out?
16:16:19 <scottda> One question is: Can state of the volume be checked in the API to provide mutual exclusion i.e. distributed locking
16:16:27 <hemna> I'd rather not wait until Tokyo ?
16:16:41 <jgriffith> DuncanT: the thing there is it may not "solve" the races as they are today, but it will completely change the flow
16:16:42 <thingee> jgriffith: a solution that has been accepted across different projects as well.
16:17:06 <dulek> hemna: +!
16:17:12 <bswartz> hemna: +1
16:17:13 <geguileo> hemna: +1
16:17:14 <jgriffith> ok..
16:17:19 <jgriffith> I guess I've said my part
16:17:30 <jgriffith> I'll remove my -2's and let other people speak up
16:17:32 <jgriffith> thanks!
16:17:32 <hemna> jgriffith, so thanks for bringing this up
16:17:39 <smcginnis> hemna, geguileo: Do the two of you want to organize a hangout for this?
16:17:53 <hemna> this is a pretty critical change and I think we all want to make sure we are doing the right thing.
16:17:58 <hemna> smcginnis, sure
16:18:09 <geguileo> But the hangout would be for the API races
16:18:11 <hemna> smcginnis, I'll work with geguileo on setting up a time for it.
16:18:14 <geguileo> Or for removing the locks?
16:18:20 <hemna> geguileo, it's all related though
16:18:24 <smcginnis> geguileo: It seems they are related, so both.
16:18:35 <smcginnis> hemna: Thank you.
16:18:40 <geguileo> Ok, but removing the locks is more complicated
16:18:47 <bswartz> in the past, it's worked to schedule a conference right after this meeting (1700UTC on wednesday)
16:19:04 <smcginnis> #topic Removal of V1 API
16:19:13 <smcginnis> jgriffith: You again. :)
16:19:15 <jgriffith> :)
16:19:29 <jgriffith> So there has been a lot of stuff going on around this lately
16:19:54 <jgriffith> I just wanted to make sure the Cinder folks were all on the same page here, as there hasn't been much input from Cinder core on this
16:20:17 <smcginnis> Bottom line is, v1 can't go away as soon as we had hoped, right?
16:20:30 <jgriffith> right :)
16:20:31 <e0ne> even more: we can't disable it too
16:20:31 <smcginnis> We have a lot of consumers of the API that just aren't ready.
16:20:32 <jgriffith> that's pretty much it
16:20:39 * jungleboyj had wished it would go away in Kilo.  or Liberty.  :-)
16:21:10 <jgriffith> honestly I think the answer is in fact microversions anyway after folks were talking about it this morning
16:21:16 <jgriffith> then we just don't have this problem any longer
16:21:20 <DuncanT> Trouble with no disabling it in devstack is we don't see all the failures until we do
16:21:22 <e0ne> jgriffith: do you have any ideas how to force vendors to use api v2?
16:21:28 <hemna> jgriffith, +1
16:21:31 <jgriffith> DuncanT: yeah, it's a vicious loop
16:21:31 <e0ne> DuncanT:  +2
16:21:35 <scottda> Shameless plug for microversions spec: https://review.openstack.org/#/c/223803/3
16:21:44 <jgriffith> scottda: +1
16:21:45 <bswartz> can someone explain why the v1 is so hard to kill when the official openstack deprecation policy is 1 release after?
16:21:54 <smcginnis> scottda: Very optimistic about that.
16:21:57 <jgriffith> bswartz: becasue we changed our response codes
16:22:03 <DuncanT> microversions don't fix that much, since we need to empulate the V1/V2 behaviour forever with microversions
16:22:04 <hemna> bswartz, because some clients were still stuck on v1 I thinks.
16:22:13 <jgriffith> bswartz: and we honestly don't have enough pull/activity outward to fix that everywhere
16:22:16 <e0ne> DuncanT: +2 again
16:22:29 <bswartz> deprecation means those clients just have to stay with an older version though
16:22:29 <DuncanT> bswartz: Pissing off customers is bad, whatever the policy says
16:22:33 <jgriffith> DuncanT: not following?
16:22:50 <bswartz> if you don't force them to move, then they never will
16:22:51 <smcginnis> In the ML someone had pointed out a good list of libraries still consuming the V1 API, beyond osc and cinderclient.
16:22:57 <hemna> bswartz, +1
16:22:58 <DuncanT> jgriffith: With microversions, any client can ask for the minimum version
16:22:59 <bswartz> you have to make it more painful to stay on v1 than it would be to move to v2
16:23:07 <smcginnis> bswartz: That's the tricky part.
16:23:09 <jgriffith> DuncanT: if you use microversioning techniques you can do things like specify in the call what version to use and thus what response you expect
16:23:14 <hemna> bswartz, but on the same token....v2 better work :P and we've had stability issues
16:23:24 <jgriffith> DuncanT: and if they choose to do so, then so beit
16:23:35 <jgriffith> DuncanT: the point is that code never goes away, and probably shouldn't
16:23:40 <jgriffith> DuncanT: that's kind of the whole point
16:23:52 <jgriffith> DuncanT: and it makes us be "better" in how we do our API
16:24:14 <DuncanT> jgriffith: Yes, but since any new client might come along and expect the old (base version) behaviour, you can't change datastructures etc in such a way to improve the behaviour (e.g. lockless algorithms) unless you have a way of emulating the old behaviour on top of it
16:24:15 <hemna> deprecate it, move all the clients to default to v2, and leave the v1 code in place to rot.
16:24:16 <jgriffith> DuncanT: if somebody wants to sit on one version "forever" then that should be ok
16:24:24 <e0ne> DuncanT: it means we need  CIs for each version
16:24:30 <smcginnis> So we can deprecate APIs, but removal is another matter.
16:24:32 <smcginnis> hemna: +1
16:24:37 <hemna> yup
16:24:47 <ameade> hemna: maybe even one more step of defaulting to v1 off
16:24:49 <jgriffith> DuncanT: My contention is that if your API interface has that sort of thing in it, it's broken
16:25:01 <jungleboyj> hemna: +1
16:25:07 <DuncanT> jgriffith: Our API has that sort of thing right now....
16:25:08 <hemna> we could make it a point to document the fact that we want folks to move to V2 and talk about it in the panel discussions, etc to help promote operators moving to V2.
16:25:10 <smcginnis> ameade: Tried that. It got reverted this morning.
16:25:11 <jungleboyj> Need to get more people to V2 so we can stabilize it.
16:25:15 <e0ne> hemna: how can we get list of "all clients"?
16:25:26 <jungleboyj> hemna: Not a bad idea.
16:25:29 <bswartz> the strategy we use with microversions is to prevent you from using new features until you stop using old features (basically you have to make your client compatible with the modern API if you want anything new)
16:25:37 <e0ne> hemna: good idea
16:25:38 <jgriffith> Ok....... so looks like this topic was a bomb as well :(
16:25:43 <DuncanT> e0ne: There was a list of the most popular clients on the mailing list thread
16:25:51 <smcginnis> hemna: Promotion is probably the best we can do. +1
16:26:00 <jgriffith> that's all I had really
16:26:00 <hemna> smcginnis, well it can't hurt at least.
16:26:14 <e0ne> DuncanT: and we are blocked by os-cloud-config project now
16:26:25 <smcginnis> I would like to reach out to those clients from the ML and at least make sure they are aware of the v2 api.
16:26:32 <hemna> the more we promote it, the better and hopefully we'll get ops to start moving to it, instead of staying on v1 forever.
16:26:32 <jungleboyj> jgriffith: YOu are good and finding those.
16:27:11 <jungleboyj> smcginnis: Yeah, the more people we can convince to move the better.
16:27:24 <smcginnis> OK, probably as far as we can go for now. jgriffith: Good to move along?
16:27:31 <jgriffith> yep
16:27:31 <navneet> if we can help clients to move to newer versions then would it help?
16:27:40 <jgriffith> navneet: yes!
16:27:47 <smcginnis> #topic Design Summit sessions
16:27:49 <navneet> I mean some way to emulate for sometime with a warn
16:27:53 <DuncanT> navneet: Absolutely
16:27:57 <smcginnis> #link https://etherpad.openstack.org/p/cinder-mitaka-summit-topics
16:28:07 <smcginnis> Thanks thingee for going through these last week.
16:28:24 <smcginnis> I don't want to spend too much more time on it, but everyone please take a look.
16:28:51 <smcginnis> So we have 4 fishbowl slots, but 2 topics listed so far.
16:29:13 <smcginnis> I seem to remember one working session that might have been a good candidate for a fishbowl.
16:29:37 <smcginnis> Does anyone else have any other needs for those, or should we give those slots back for someone else?
16:30:24 <DuncanT> smcginnis: Any other sessions that can be expanded into a fishbowl?
16:30:38 <smcginnis> DuncanT: That's what I'm wondering.
16:30:48 <smcginnis> We probably have some there that could be.
16:30:53 <bswartz> fishbowls don't really have more time, it's just more space and more publicity
16:30:54 <smcginnis> Or a combination of both.
16:31:02 <DuncanT> smcginnis: Microversions and experimental APIs could easily take up more than a session depending on how they go down
16:31:02 <e0ne> smcginnis: what about "Attaching a volume without Nova" session?
16:31:21 <smcginnis> Publicity being a good thing I would think.
16:31:24 <jungleboyj> What about the Cinder Could/Should be the next ViPR discussion?
16:31:26 <xyang> e0ne: that is a good one
16:31:32 <DuncanT> jungleboyj: +1
16:31:39 <smcginnis> DuncanT: Given our API issues, that could be a good one to make sure it has wider visibility.
16:31:41 <jungleboyj> DuncanT: ++ to your idea as well.
16:32:00 <bswartz> smcginnis: publicity can be bad if it invites people to come and offer useless opinions on stuff they know nothing about
16:32:01 <tbarron> jungleboyj: +1
16:32:05 <thingee> jungleboyj: +1
16:32:13 <e0ne> jungleboyj: +1
16:32:16 <smcginnis> e0ne: no nova could be, but maybe the ViPR framed discussion might work better for the same intent?
16:32:23 <DuncanT> bswartz: You cynic ;-)
16:32:38 <bswartz> generally publicity is good though -- in this community there's not much problem with people distracting from conversations
16:32:49 <smcginnis> bswartz: We'll just have DuncanT escort them from the room. :)
16:32:58 <jungleboyj> Could we use one as an add on to the Nova Cross Project discussion?
16:33:11 * DuncanT plans on katana shopping in Tokyo anyway.....
16:33:20 <scottda> jungleboyj: +1
16:33:21 <jungleboyj> DuncanT: ++
16:33:34 <e0ne> :)
16:33:35 <smcginnis> scottda: Sorry, you're more on top of the cross project discussion than me. Input?
16:33:58 <scottda> I think Cinder could benefit from discussing NOva issues...
16:34:26 <scottda> I've asked to schedule something on the Nova agenda..
16:34:30 <smcginnis> Should we change the AZ topic to be general nova-cinder, or do we need both?
16:34:38 <smcginnis> scottda: Oh, good!
16:34:45 <navneet> how about discussing Ironic with cinder?
16:34:47 <scottda> https://review.openstack.org/#/c/223803/3
16:35:05 <scottda> oops, wrong link!
16:35:14 <scottda> https://docs.google.com/spreadsheets/d/1MZVwxv8t6sM15Kct5i7yOS-8-NCvqsW742s5Y_LDyjg/edit#gid=816860825
16:35:19 <e0ne> navneet: actually, it's an "Attaching a volume without Nova" session
16:35:42 <DuncanT> smcginnis: I think AZs will need the time, since so many people have different desire
16:35:48 <tbarron> I think AZ discussion needs its own slot
16:35:56 <smcginnis> DuncanT: OK, good point.
16:36:09 <navneet> e0ne: oh sorry...thought its general ideas on summit sessions
16:36:16 <jungleboyj> smcginnis: I proposed that as I think we have a number of Nova/Cinder issues to discuss.  We will easily fill the time that scottda has asked for.
16:36:57 <scottda> Yeah, and we could use some time on the Cinder agenda to discuss Nova/Cinder from the Cinder side.
16:37:00 <smcginnis> jungleboyj: scottda: Do you think we should have a Nova Cinder meeting and a Cinder Nova meeting?
16:37:12 <jungleboyj> :-)
16:37:13 <mriedem1> AZs, new api microversions, extend volume and multiattach are the current cross project things right?
16:37:16 <scottda> haha...actually yes
16:37:17 <smcginnis> scottda: Fishbowl or working session?
16:37:22 <jungleboyj> mriedem1: Thank you sir.
16:37:35 <mriedem1> those 4 things are too much for a single session
16:37:44 <tbarron> +1
16:37:47 <mriedem1> maybe some time can be carved out on meetup style friday
16:37:50 <scottda> mriedem1: so far, I think that's it...maybe future changes to the API
16:38:01 <smcginnis> So how's this...
16:38:03 <mriedem1> scottda: yeah i lump that in with microversions
16:38:27 <smcginnis> For the two extra slots we do a Nova meeting and the ViPR (or should that be CoprHD) discussions?
16:38:36 <scottda> I started this thinking it was for the Nova meeting on Cinder-Nova: https://etherpad.openstack.org/p/NovaCinderMitakaSession
16:38:42 <smcginnis> Then we can get a meetup later in the week if needed.
16:38:54 <mriedem1> smcginnis: has johnthetubaguy agreed to doing 2 nova slots with cinder?
16:39:06 <mriedem1> some of the nova natives might get restless
16:39:07 <smcginnis> mriedem1: I have not asked.
16:39:08 <jungleboyj> smcginnis: I like those ideas, but I proposed them.  :-)
16:39:09 <mriedem1> :)
16:39:12 <DuncanT> smcginnis: We should rename the ViPR session though
16:39:21 <cebruns> smcginnis: Sounds good
16:39:21 <smcginnis> DuncanT: Agreed.
16:39:47 <smcginnis> mriedem1: I think we probably would even have enough to discuss on the Cinder side of things even if most Nova can't make it.
16:39:55 <smcginnis> mriedem1: But I will ask.
16:39:58 <jgriffith> yeah, should probably remove vipr and coprhad from the titles altogether
16:40:10 <johnthetubaguy> I am good with us having some time in Nova on Cinder things, if we have some good concrete things to talk about
16:40:15 <xyang> jgriffith: what is a cinder driver?:)
16:40:27 <cebruns> jgriffith: I like having those in there "and the fight" part.  :)
16:40:29 <smcginnis> xyang: What is Cinder?
16:40:38 <xyang> jgriffith: I think that is the session in Atlanta
16:41:03 <navneet> xyang: mike can take a session on the topic :)
16:41:07 <xyang> smcginnis: in atlanta we had a session on vipr, I think it is called "what is a cinder driver"
16:41:15 <jungleboyj> smcginnis: Cinder is a state of mind ... being ...
16:41:27 <smcginnis> ;)
16:41:31 <scottda> jungleboyj: Thank you Grasshopper
16:41:36 <smcginnis> I'll get it renamed before submitting it.
16:41:40 <jungleboyj> scottda: :-)
16:41:57 <smcginnis> OK, working sessions...
16:42:02 <smcginnis> We have five slots.
16:42:09 <smcginnis> Are we good with the five now listed there?
16:42:31 <smcginnis> Or are there some sprint topics that should be moved up?
16:42:31 <DuncanT> get_extra_metadata seems a bit thin for a session
16:42:41 <DuncanT> I'd say that was a sprint topic
16:42:45 <smcginnis> DuncanT: agree
16:42:52 <e0ne> DuncanT: +1
16:42:59 <hemna> yuh
16:43:12 <jungleboyj> DuncanT: Someone from IBM added that.
16:43:20 <DuncanT> Soft Dependencies for Drivers could be entertainingly argumentative
16:43:23 <jungleboyj> That shouldn't be a working session.
16:43:28 <jungleboyj> Sorry I didn't catch that.
16:43:45 <smcginnis> jungleboyj: You need to watch all of IBM better.
16:43:46 <smcginnis> :P
16:43:54 <jungleboyj> smcginnis: :-P
16:43:58 <jungleboyj> Watch it man.
16:44:00 <DuncanT> Functional Testing is something we could really benefit from
16:44:18 <jungleboyj> That is diablo_rojo 's job
16:44:29 <smcginnis> DuncanT: I would love to see that move forward.
16:44:49 <smcginnis> jgriffith: Should we make that a working session?
16:44:58 <DuncanT> smcginnis: be nice to see a definite plan
16:45:53 <jgriffith> probably
16:46:04 <smcginnis> The A-A discussion might be a better working session though.?
16:46:07 <jgriffith> DuncanT: the plan is for people to actually spend time to do it
16:46:19 <jgriffith> DuncanT: create tests, add the job to the gate
16:46:24 <jgriffith> DuncanT: that IS the plan
16:46:33 <DuncanT> jgriffith: So still black-box testing?
16:46:39 <jgriffith> DuncanT: ?
16:46:43 <dulek> smcginnis: It is big topic and some stuff changed since last summit.
16:47:04 <smcginnis> Would be good to have at least a sprint on that to make sure folks understand what the goal of functional testing is.
16:47:05 <dulek> smcginnis: We thought that everything is clear on A/A approach, but I'm not sure now.
16:47:15 <DuncanT> jgriffith: On;y driving things from the external APIs.... no stress testing internal bits of code or anything?
16:47:44 <hemna> dulek, I think there are some issues that need ironing out, such as the picking up of messages on the message queue
16:47:44 <jgriffith> DuncanT: external API's?
16:47:51 <smcginnis> So A-A is maybe a little more important to get in a working session I think.
16:47:57 <hemna> as geguileo talks about in his blog post, but I think there are issues with it.
16:47:58 <jgriffith> DuncanT: I think "fucntional" testing is pretty clear
16:48:00 <DuncanT> jgriffith: Or can we e.g. stress test any atomic code in a tight loop with no API involvement?
16:48:23 <jgriffith> DuncanT: functional would imply to me that you use the API like a consumer would
16:48:27 <dulek> hemna: I'm also not completely convinced to this idea. Working session might help.
16:48:29 <DuncanT> jgriffith: It isn't, hense the question. I'm good with either answer, just like to know what you mean
16:48:41 <jgriffith> DuncanT: there's nothing keeping you from doing what you are suggesting in unit tests
16:48:44 <geguileo> hemna: I think the picking up of messages is the easiest part (although my post as it is has a problem)
16:49:09 <DuncanT> jgriffith: unit tests are not supposed to be long, and they're generally supposed to mock out db and similar
16:49:09 <hemna> geguileo, we should chat
16:49:11 <hemna> :)
16:49:16 <jgriffith> DuncanT: Ok... so by cinder/tests/functional, I intended "functonal" to be: Spin up Cinder, run tests against Cinder using the API
16:49:19 <smcginnis> OK, I'll put A-A there. But we obviously need to talk functional testing at some point if for no other reason than to make sure we all have the same definition.
16:49:20 <geguileo> hemna: And I should write some specs :-(
16:49:22 <jgriffith> DuncanT: does that help?
16:49:37 <DuncanT> jgriffith: Stress testing the LVM wrappers against real for example isn't a unit test thing
16:49:37 <jgriffith> DuncanT: we could also look at what others are doing
16:49:50 <hemna> jgriffith, +1
16:49:50 <smcginnis> So sprints...
16:49:54 <jgriffith> DuncanT: no, it's not
16:49:57 <DuncanT> jgriffith: That helps. Thanks.
16:50:00 <smcginnis> thingee: How many are "a lot" ?
16:50:17 <jgriffith> DuncanT: but that's an interesting idea, and possibly something to look at
16:50:40 <smcginnis> I think I did see we can schedule multiple into one slot.
16:50:52 <smcginnis> Some of these look like they might take a while. Some are probably pretty quick.
16:51:02 <jgriffith> DuncanT: ie just importing/exploiting a module at a functional level.  Different than what I envisioned
16:51:19 <smcginnis> I guess I'll see how many we actually have and if we need to cull the list or combine some of them.
16:51:22 <jgriffith> DuncanT: the thing that started this was the idea of getting API tests somewhere besides Tempest IIRC
16:51:29 <jungleboyj> smcginnis: Hasn't it usually been pretty fluid in the past?
16:51:43 <smcginnis> jungleboyj: Yeah, I thought so.
16:51:45 <jgriffith> I see no reason you couldn't do both
16:52:06 <smcginnis> So maybe we just schedule open slots and just work through them?
16:52:16 <smcginnis> I still need to actually see how the scheduling process actually works.
16:52:24 <smcginnis> But I think you are right jungleboyj.
16:52:46 <smcginnis> OK, I think I'm good on sessions. Anyone have anything else on that topic?
16:53:18 <smcginnis> OK, moving on. Feel free to ping me if you think of anything.
16:53:25 <smcginnis> #topic Unfinished business
16:53:33 <smcginnis> #link https://etherpad.openstack.org/p/cinder_mitaka_unfinished_business
16:53:49 <smcginnis> So I know there have been several initiatives started over the last few releases.
16:53:56 <smcginnis> Some of them I'm kind of aware of
16:54:07 <smcginnis> But I still hear of others I didn't know about.
16:54:33 <smcginnis> I would like to try to collect all of these in one place so we can either decide we still need them and get them going again.
16:54:50 <xyang> smcginnis: I put note there objects and ABC should be two separate things
16:54:53 <smcginnis> Or decide they are no longer relevant and should either be rolled back or left as is.
16:55:13 <smcginnis> xyang: Good point. We have the objectization and we have the ABC work.
16:55:18 <smcginnis> Two separate things really.
16:55:25 <scottda> What about task flow
16:55:32 * scottda ducks
16:55:34 * smcginnis shudders
16:55:39 <smcginnis> Yeah
16:55:47 <smcginnis> I wasn't sure to even bring it up.
16:55:57 <scottda> That's why I did it for you.
16:55:58 <jungleboyj> scottda: You had to go there?
16:56:00 <jungleboyj> :-)
16:56:01 <smcginnis> Since we've spent so much time on it already.
16:56:03 <smcginnis> :)
16:56:13 <smcginnis> That's one I think I want to leave alone.
16:56:19 <smcginnis> But probably should be noted.
16:56:21 <hemna> discussions about taskflow are noops
16:56:25 <jgriffith> smcginnis: is a smart man
16:56:27 <xyang> there's some refactoring work done on task flow.  I don't know how much is left
16:56:28 <smcginnis> hemna: +1
16:56:34 <smcginnis> jgriffith: ;)
16:56:47 <smcginnis> xyang: Done? Or to be done?
16:56:59 <xyang> smcginnis: some are done in liberty
16:57:03 <xyang> patches merged
16:57:05 <dulek> xyang: Well, that was just refactoring for readability.
16:57:31 <xyang> dulek: alright.  so you have future plans?
16:57:32 <dulek> xyang: I don't know if it actually improves it. *I* feel like I understand this code.
16:57:35 <smcginnis> Not to rathole on taskflow (yet again) but my stance is I'm not opposed to.
16:57:45 <smcginnis> And I wouldn;t be against anyone working on it.
16:57:56 <smcginnis> But I don't want it to get a lot of focus and be a distraction.
16:58:07 <dulek> One thing is taskflow'ization of other calls.
16:58:13 <smcginnis> OK, two minute warning.
16:58:18 <dulek> Other thing is leveraging it's persistence.
16:58:19 <eharney> python 3 support seems to be going fine to me.   we have a plan and it's moving forward
16:58:32 <smcginnis> Please take a look at the etherpad and put in anything you can think of.
16:58:32 <dulek> I think both of these can wait - we have bigger problems.
16:58:35 <hemna> eharney, +1
16:58:49 <smcginnis> Especially those that have been around for a long time.
16:58:57 <smcginnis> #topic Open discussion
16:59:08 <smcginnis> Any final quick things?
16:59:22 <xyang> about backport
16:59:30 <xyang> when can we backport to liberty
16:59:48 <jungleboyj> xyang: Fixes?  Good question?  I don't have +2 there yet.
16:59:49 <eharney> when is rc2?
16:59:49 <smcginnis> After the final cut I think. thingee?
17:00:08 <smcginnis> Let's take it to the cinder channel.
17:00:12 <smcginnis> Thanks everyone!
17:00:16 <smcginnis> #endmeeting