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