16:00:01 #startmeeting Cinder 16:00:02 Meeting started Wed Apr 6 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:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:05 The meeting name has been set to 'cinder' 16:00:08 hello 16:00:11 Courtesy ping: dulek duncant eharney geguileo winston-d e0ne jungleboyj jgriffith thingee smcginnis hemna xyang tbarron scottda erlon rhedlind jbernard _alastor_ vincent_hou kmartin patrickeast sheel dongwenjuan JaniceLee cFouts Thelo vivekd adrianofr mtanino yuriy_n17 karlamrhein diablo_rojo jay.xu jgregor baumann 16:00:12 Hello 16:00:13 Hello! 16:00:15 hi 16:00:17 .o/ 16:00:17 hi 16:00:18 smcginnis: Thanks! 16:00:19 Hello :) 16:00:20 hi 16:00:20 Hi 16:00:21 hi 16:00:22 hi 16:00:22 hi 16:00:25 hey 16:00:25 hi 16:00:26 Hey there 16:00:27 hi 16:00:32 Hi (parallel meeting, so I'll be reading using one eye only) 16:00:42 Hi 16:00:44 dulek: ;) 16:00:45 hi 16:00:59 hi 16:01:03 dulek .) 16:01:05 Thanks to everyone that stepped up to run the meeting last week. 16:01:11 Horrible timing on my side. 16:01:19 Forgot about Europe DST. 16:01:33 hi 16:01:40 Ended up the one spot where I couldn't get on - in the middle of the sea with no signal. 16:01:50 #topic Release Status 16:01:50 Was your kid barfing at the time? 16:02:00 #info RC-2 will be final Mitaka release 16:02:05 hi 16:02:09 o/ 16:02:16 Hi 16:02:22 hi 16:02:35 Hi! 16:02:39 Release is set. We have a few backports for the first update, but I think we can declare M mostly baked. 16:02:51 Great work everyone on all that we got done the last cycle. 16:03:07 smcginnis: it's a good news! 16:03:18 My only regret is that I couldn't code replication support a third time. 16:03:26 Swanson: :P 16:03:30 ;) 16:03:31 Swanson: hush! 16:03:37 Swanson: it can be arranged ya know 16:03:44 With that - time to start focusing on Newton. 16:03:47 jgriffith, I'll be good. 16:03:50 Repl v3, here we come! 16:03:50 Swanson: Tiramasu has you covered in Newton 16:04:09 #link https://etherpad.openstack.org/p/cinder-spec-review-tracking Spec and review focus tracking. 16:04:10 Swanson, DuncanT: yes:) 16:04:20 * jgriffith still isn't convinced that's a great idea... but ok :) 16:04:20 Tasty tiramisu. 16:04:36 jgriffith: You just want more cheesecake. 16:04:45 smcginnis: but of course 16:04:46 jgriffith: which one? Tiramisu or spec tracking? 16:04:54 Hah! 16:04:55 and whoever sent me one last week, thank you!! It was yummy 16:05:06 xyang: My question too. 16:05:12 :) 16:05:13 * bswartz quietly prepares double-fudge-brownie spec... 16:05:16 Tiramisu, I'm nervous about volume only rep failovers 16:05:38 * DuncanT decides to name all his future after good single malt, just in case 16:05:43 we have to pre-order tiramisu for our beer night at summit 16:05:43 jgriffith: I definitely think that will be an active summit session. 16:05:48 DuncanT, +1 16:05:49 DuncanT: Smart man! 16:05:53 but no need to rat hole on that here 16:06:02 So spec tracking... :) 16:06:04 Better left for the summit 16:06:09 I just put a few things in there for now. 16:06:28 jgriffith: you apparently changed your mind again:), but let's discuss later 16:06:28 We can resort and prioritize things as we go. Probably some better ideas after the summit. 16:07:10 I'd like to see if we can use this better for focusing reviews. 16:07:24 xyang: nah... I'll stay out of your way 16:07:24 Seems to have worked well for Nova at least. 16:07:38 #link http://releases.openstack.org/newton/schedule.html Planned Newton release schedule 16:07:41 smcginnis: Maybe a Friday working session for setting and sorting priorites? 16:07:54 jgriffith: we need your input 16:08:01 scottda: Good idea. I'll add that to the etherpad to make sure we don't miss it. 16:08:13 smcginnis: did I miss the link? 16:08:25 jgriffith: Which one? 16:08:36 smcginnis: nm found it ;) 16:08:37 sorry 16:08:38 Review focus: https://etherpad.openstack.org/p/cinder-spec-review-tracking 16:08:52 jgriffith: No worries. Multiple streams going at the same time. 16:09:21 I'll publish the Cinder specific deadlines on the newton release schedule soon. 16:09:33 I'm thinking our deadlines in Mitaka worked well for the most part. 16:09:49 Anyone have any input or opinion that any of it should be different for N? 16:09:50 smcginnis: will we have the same deadlines for new drivers? 16:10:10 e0ne: That's my thought so far, unless someone feels strongly otherwise. 16:10:34 smcginnis: from my PoV it works better 16:11:04 OK, well if anyone has any strong opinions otherwise, just let me know. 16:11:10 But I did think it went well. 16:11:24 #topic Summit session planning 16:11:26 I think the same deadlines would be good. 16:11:34 #link https://etherpad.openstack.org/p/newton-cinder-summit-ideas Summit session planning 16:11:54 I need to get the sessions added to the schedule. 16:12:21 I'll start going through and allocating topics to specific timeslots, hopefully this week yet. 16:12:33 Please add any topics to the etherpad. 16:13:12 We can adjust things, but the biggest ones I'll put in the fishbowl sessions, larger topics for the group in working sessions, misc. topics in the Friday work day. 16:13:37 We were able to power through topics on the last day in Tokyo. 16:13:57 So make sure anything you want discussed is on there so it's not missed. 16:13:59 hemna: do we want session about privsep in os-brick? 16:14:01 Please also note if you thing a topic will be contentious / uncontentious - we waste a fair amount of time on things where there's no disagreement some summits 16:14:16 e0ne: Looks like it's under the nova session list. 16:14:31 e0ne, I'm not sure why. it's about to land :) 16:14:31 DuncanT: Good point. 16:14:38 now that all the privsep stuff has landed 16:14:47 Or there is one more 16:14:51 We want to make sure folks have had time to digest and discuss ahead of time so it's productive. 16:14:54 smcginnis: DuncanT so only things that we can argue about :) 16:14:57 we just need folks to test it. it's basically ready to roll. 16:15:20 But we also don't need to dedicate a topic just as a formality if everyone's already in agreement. 16:15:21 hemna: good to know it 16:15:28 jgriffith: Yeah, entertainment value. :) 16:15:34 smcginnis: :) 16:15:37 e0ne, https://review.openstack.org/#/c/277224/ 16:15:47 hemna: It's kind of broken from my PoV, given we're not in a rush anymore, I'd rather see it evolve slightly closer to the final vision before we merge it now 16:15:55 No, but really anything that needs some discussion or needs to make sure everyone is aware of. 16:16:03 hemna: trying to get my NFS CI job added to os-brick so i can test it with that 16:16:08 hemna: It's still in my TODOs list 16:16:11 I actually think we have enough time, based on the number of slots we have. 16:16:13 e0ne, all the deps have landed, and the 3PAR and pure storage CI have passed now. (they had been failing due to the dependencies not landing) 16:16:22 eharney, sweet! 16:16:29 hemna: Even if it is only one or two example calls being done properly 16:16:35 So if we have a few that are just small updates, I'd rather have that than something coming out of the blue that most folks weren't aware of. 16:17:02 DuncanT, well, I think this is a decent first step. I have several other patches in os-brick that are depending on this getting in (nova/cinder using os-brick's lvm) 16:18:26 #topic Nova-Cinder API discussion 16:18:29 hemna: Ok, I don't think it's massively harmful to merge what's there, I just really want to see an example of doing it properly so we can start working on it. Maybe ask Angus to do a parallel patch of one call site to start looking at that though, and allow other things to progress? 16:18:33 sheel: Hi! 16:18:38 smcginnis: hi 16:19:02 smcginnis: it was regarding having idea about what was discussed in cinder-nova api discussions 16:19:08 sheel: I can give an update, since you were looking for a volunteer. 16:19:09 DuncanT, yah I think that's doable as follow ups. 16:19:14 #link https://etherpad.openstack.org/p/cinder-nova-api-changes 16:19:20 smcginnis: I think scottda have updated something 16:19:25 scottda: yes please 16:19:35 There are a few topics, all related somewhat... 16:19:57 Getting multi-attach in Nova is one of them. And that leads to possible changes in Cinder. 16:20:11 You can see we have 4 alternatives in the etherpad. 16:20:35 scottda: yes 16:20:49 hemna created a nice graph of Volume attach: #link https://www.gliffy.com/go/publish/image/10360157/L.png 16:21:08 At this point, we are wanting got get as much info out as possible, thus the graph. 16:21:21 We could use similar graphs for detach and Nova live migration. 16:21:29 scottda, I was just thinking about that 16:21:34 From there, we hope to examine the various alternatives. 16:21:48 jgriffith: Have you had a chance to look at that etherpad. I think one of the alternatives was what you were pushing for. 16:21:49 And resolve them at the Summit with a Big Cage Match 16:21:54 scottda, if I get time I can work on creating a graph for live migration as well. 16:22:05 hemna: That's be swell. 16:22:05 scottda: Would love to have pretty graphs for all the workflows. 16:22:08 smcginnis: yep, and I added some things including comments 16:22:10 I think that could benefit everyone. 16:22:14 jgriffith: Great, thanks! 16:22:17 and questions 16:22:28 I've seen some usage of PlantUML in other projects. 16:22:50 Don't know if we have a standard, but that's a pretty convenient one that would allow us to include the code in source and have it reviewed. 16:22:54 Just a suggestion. 16:23:08 smcginnis: Yes, on that note, having a good , free tool for call graphs and flow charts would be great. Lotsa stuff could benefit. 16:23:17 smcginnis, I just did a search for web based uml tools 16:23:22 smcginnis: +1 16:23:27 I'd like one that is free that produces something like what I did. 16:23:37 smcginnis: I like it, OSS and free 16:23:47 Prety easy to use too. 16:23:58 It really makes a difference for these kind of complex design discussions. 16:24:00 and text language input for repo is a big plus 16:24:15 Anyway, that's where the nova-cinder api stuff is today. 16:24:15 http://plantuml.com/ that one ? 16:24:24 hemna: Yep, that's it 16:24:31 I think there are python libraries for it. 16:24:38 Integration with things like Confluence, etc. 16:24:43 With another meeting today at 2100- UTC in #openstack-meeting-cp 16:24:49 is there a GUI for editing ? if so, I can check it out and try to reproduce the same attach graph 16:25:19 hemna: Maybe. I've only done text updates to generate the images. 16:25:20 hemna: we have other tools as well for same thing like Seqdiag 16:25:23 :( 16:25:25 hemna: Usually pretty good about layout. 16:25:32 hemna: Syntax is super simple. 16:25:36 ok, I'd rather not have to spend time learning some text syntax 16:25:51 ok anyway 16:26:03 Super super simple. :) 16:26:19 But fair enough. I'd rather see something than nothing. 16:26:48 Anything else on the nova-cinder topic to cover? 16:27:01 Not from me. 16:27:06 I added a 4th alternative yesterday 16:27:12 would be nice if folks can chew on it 16:27:53 scottda: do we have only multi attach in this discussion ? 16:28:17 sheel: No. multi-attach just brings forth many issues. 16:28:40 scottda: ok..will go through etherpad for more details.. 16:28:49 scottda: thanks for pointers 16:28:57 Having some way to do a Cinder force-detach without Nova (in the case where Nova instance is gone) is another... 16:29:09 hemna: umm... I'm confused 16:29:13 But that kind of depends on attach/detach changes for multi-attach. 16:29:15 scottda, hemna: is the plan to fix all multi attach related issues in Nova in Newton? 16:29:31 That would be great if we could. 16:29:39 xyang, the plan is to get multi-attach working :) 16:29:41 hemna: you just took my proposal for initialize_connection which already does part of it and moved it to reserve which *was* specifically JUST for reserving the volume? 16:29:46 And Nova live migration requires a way to update certain attach info (i.e. compute host). But that also depends on changes... 16:29:51 hemna: ok:) 16:29:51 hemna: That would also be cool! :) 16:30:26 hemna: jgriffith Will you both be at the meeting today to discuss ? 16:30:47 scottda: time? 16:31:01 2100 UTC 1500 MDT 16:31:12 #openstack-meeting-cp 16:31:19 scottda: yeah. I can be there 16:31:25 scottda: please ping me if I forget :) 16:31:40 jgriffith, basically, yes because it will give you the correct attachment_id throughout the entire process of the workflow. if you look at the code now, the volume_attachment table entry doesn't even exist until attach is called, which is the end of the process. 16:31:41 It will be a lot more fun with both of you there :) 16:31:51 I would definitely feel better if all of you guys are on the same page. :) 16:32:12 it's a much cleaner and explicit/straight forward approach IMHO. no magic lookup/discovery stuffs needed. 16:32:45 There is a sign up in the etherpad for interested people and you will be pinged for the meeting. 16:32:52 hemna: but you're just taking my proposal that you haven't given any feedback on and duplicating/moving it up one step further where IMO it doesn't belong? 16:33:13 jgriffith, yup, because I don't like your proposal. 16:33:19 hemna: ok 16:33:22 hemna: jgriffith Let's get our alternatives and graphs together and discuss at today's meeting. 16:33:29 scottda: +1 16:33:32 scottda, +1 16:33:59 Have a good old fashioned debate 16:33:59 #topic Cinderclient support of /v3 endpoint and microversions 16:34:09 Hi 16:34:11 scottda: Your a popular guy today. 16:34:14 *you're 16:34:46 Just a prod to review cinderclient changes for microversion support: 16:34:54 #link https://review.openstack.org/#/c/300028 16:35:02 support for /v3 endpoint ^^ 16:35:21 #link https://review.openstack.org/#/c/301941/2 16:35:29 support for microversions ^^ 16:35:45 scottda, smcginnis: do we have plan to move extension APIs to core APIs in Newton? Otherwise we can't use microversion on them 16:35:46 #link https://review.openstack.org/#/c/300585 16:35:59 ameade: patch for /v3 endpoint in devstack ^^ 16:36:22 xyang: We had discussed it, and we should. Thanks for the reminder. 16:36:34 xyang: That's what manila did, right? 16:36:41 smcginnis: yes 16:37:05 +! 16:37:06 +1 16:37:09 xyang: How hard would it be to do? 16:37:18 s/to do/for you to do/ 16:37:25 (see what I did there?) 16:37:26 moving the extensions to core was susprisingly easy 16:37:26 scottda: in manila, it took one release to complete it 16:37:44 bswartz: it just takes time and cinder has a lot more than manila 16:38:00 xyang, scottda: sounds good 16:38:03 scottda: I think once you get one done, the rest should be easy 16:38:12 scottda: I can help as well 16:38:17 No reason why it should be slow, the patches should all be identicalish once the first on eis got right 16:38:34 IMO, it will be helpful to track this progress in an etherpad 16:38:36 DuncanT: it just takes time for things to get merged 16:38:57 I can look at doing this. xyang I'll ping you 16:39:07 scottda: sounds good 16:39:26 scottda: Anything else on this topic? 16:39:45 https://github.com/openstack/manila/commit/2467ccf223559e7542349a5336379c6ef607352c 16:40:05 example of moving extensions into core for manila 16:40:13 #link https://etherpad.openstack.org/p/move-cinder-extensions-to-core 16:40:14 bswartz: Doesn't look horrible. 16:41:01 smcginnis: coding is not hard. just takes time to get everything merged because there are so many extension apis 16:41:03 scottda: thanks 16:41:19 smcginnis: No. But please review. I hope we can make progress before the Summit 16:41:24 xyang: Yeah, it looks like something we'll just have to work our way through. 16:41:42 Certainly feasible to complete in N, but we'll need to pay attention to make sure it can. 16:41:53 scottda: Thanks! 16:42:08 #topic Deprecate cinder-all 16:42:14 DuncanT: Yeah, not sure about this one. 16:42:44 smcginnis: It's entirely true that it is untested, I wondered if anybody had ever had/see a use for it 16:42:56 IMO, it's not tested and probably not used at all. should we continut to maintain it? 16:42:59 i assume that nobody really uses this 16:43:04 smcginnis: Also whether other services (still) have a *-all binary 16:43:06 eharney:+ 16:43:19 i drop it from our packages just to make sure nobody decides to have fun with it 16:43:46 eharney: Oh, that's an interesting data point. 16:43:52 tbarron maked a good comment about it in the review 16:44:01 nova-all still exists in their tree 16:44:19 wouldn't real customers get in trouble if they did this? 16:44:34 aharney: Can you add the comment about you dropping it to the review, please? 16:44:40 and we don't use it in dev environment to my knowledge. 16:44:41 tbarron: i think it should mostly "work" in theory 16:44:43 DuncanT: ok 16:44:51 but scale? 16:45:01 seems very uncloudy 16:45:04 tbarron: Well, this still runs 3 processes. 16:45:33 eharney: TBH, I tested it today. it works. at least, I was able to create and delete a volume 16:45:37 tbarron: It certainly is in terms of running in containers for example. 16:45:39 dulek: ok, but why? 16:46:09 The issue I can see is if somebody does both cinder-all and cinder-{whatever} 16:46:16 seems to me a direction we'd want to deprecate. 16:46:37 proposal was to deprecate over a release. 16:46:50 DuncanT: if they do that, wouldn't they just get accidental HA? 16:46:51 Definitely it doens't look that cinder-all has any benefits to running every service separately. 16:46:56 That might actually be a good way to find out if anyone cares. 16:47:01 if there's a use case for it, then sure. but is there? 16:47:13 If we mark it deprecated and no one says anything, then we're probably safe removing it in O. 16:47:18 bswartz: They get craziness if they e.g. edit a config file and don't know what to restart 16:47:24 bswartz: It's more complicated - API will crash due to used port. 16:47:26 i've always assumed use case is for some all-in-one development setup, but that doesn't really exist 16:47:31 If someone complains and gives a reason for its existence, then we can un-deprecate it. 16:47:31 smcginnis: +1 16:47:35 eharney: ++ 16:47:43 But only after having been given some justification for it. 16:47:44 smcginnis+1 16:47:47 smcginnis: good point 16:47:52 our all-in-oone is devstack and we don't do it there 16:48:01 Deprecate seems safe. 16:48:06 I mostly just wanted to check if anybody knew a use for it off the cuff and hadn't seen the review, so I'm happy enough 16:48:15 DuncanT: ++ 16:48:19 +1 16:48:44 DuncanT: please link me the review -- we have the same madness in manila 16:49:21 bswartz: https://review.openstack.org/302189 16:49:48 #topic Open Discussion 16:49:58 bswartz: it's a "initial for of cinder" problem ;) 16:50:34 e0ne: "Initial fork out of Nova". I've learned that already when looking through code. :D 16:50:35 bswartz: https://review.openstack.org/#/c/302189/ 16:50:51 dulek: in manila? 16:50:54 ty 16:50:59 guys, thanks a lot for discussing on my patch https://review.openstack.org/#/c/302189/ 16:51:08 cinder forked from nova and manila forked from cinder 16:51:17 it's all forked 16:51:18 e0ne: Oh. Okay, you're right. 16:51:22 Cluster forked. 16:51:30 :) 16:51:49 we need fork from manila! 16:51:53 I've got one. Any feedback on this: https://review.openstack.org/#/c/297140/ 16:51:55 file-as-a-service 16:51:56 And neutron is forked from nova-network. Oh wait… 16:52:07 I've seen some cases where having this check could be useful. 16:52:22 If we add it, it would be nice to have in place for new drivers in N. 16:53:15 smcginnis: i'd like to give feedback on this, will take a look 16:53:44 eharney: Great, thank you. 16:53:51 smcginnis: I wanted to revisit your earlier questions about deadlines 16:53:57 bswartz: Sure! 16:54:03 smcginnis: did any drivers or features actually miss the deadlines? 16:54:09 was anyone thrown out? 16:54:11 smcginnis: I've been meaning to take a proper look at this, but at first glance I liked it - it provides much of what I hoped to get from ABCs and... didn't 16:54:18 bswartz: I think Nexenta had a couple more they wanted to add. 16:54:40 so they're waiting for newton? 16:54:41 bswartz: And one other one submitted way late, so they weren't paying any attention. 16:55:00 bswartz: I think so. Could be wrong, but if my memory is right they had something. 16:55:26 the main measure of a deadline is what happens when the deadline gets missed -- if it's all orderly then I think it was successful 16:55:32 bswartz: No one thrown out. 16:55:50 one more review request: Remove XML API https://review.openstack.org/231663 - please, help me to not meet rebase hell 16:56:01 bswartz: It seemed successful to me. Other than the one out of the blue, it seemed like everyone was aware of it and planned accordingly. 16:56:19 CI's continue to be an issue, so we may have to remove some this cycle. 16:56:33 There are a few that haven't been passing for some time now. 16:56:57 smcginnis: +1 When CI's fail all the time, we ignore them, and then broken stuff gets in like Sheepdog issue for backups. 16:57:02 e0ne: Would be nice to get that one through sooner rather than later. 16:57:18 scottda: Yeah, that's a bad one. 16:57:24 smcginnis: I'm agree with you:) 16:57:43 OK, thanks everyone. 16:57:48 #endmeeting