16:00:02 #startmeeting Cinder 16:00:02 Meeting started Wed Jun 10 16:00:02 2015 UTC and is due to finish in 60 minutes. The chair is thingee. 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:11 hi everyone 16:00:18 Hi! 16:00:20 hello 16:00:21 hey 16:00:21 hi 16:00:22 Howdy 16:00:29 hi 16:00:30 hi 16:00:32 hi 16:00:34 hi 16:00:35 hi 16:00:35 hi 16:00:46 hi 16:00:47 hi 16:00:48 hello 16:00:53 hello 16:00:53 first announcements! 16:00:57 hi 16:00:57 #topic announcements 16:01:01 #link https://launchpad.net/cinder/+milestone/liberty-1 16:01:19 #info Liberty-1 will be ending around June 25th or earlier 16:02:02 As I have mentioned in the previous meeting, June 10th (today) is purging of blueprints from L-1 16:02:12 These have been moved to L-2 16:02:21 only if they contained no working code 16:02:38 we're down to 28 bps that need code review. 16:02:50 I suspect others to be removed because of the driver deadline coming up 16:03:19 #link http://lists.openstack.org/pipermail/openstack-dev/2015-May/064072.html 16:04:01 #info June 15th proposed drivers for Liberty without passing code in Jenkins and a CI will be removed. These drivers will have to submit for the M release. 16:04:45 o/ 16:04:47 One spec will be approved this friday: 16:04:49 #link https://review.openstack.org/#/c/150511/ 16:04:52 o/ 16:04:54 The standard capabilities 16:05:09 #info standard capabilities (just the terms) will be approved this friday 16:05:23 please speak up if something isn't right there, but this is pretty straight forward 16:05:44 this is not to be confused with what I spoke at the summit which depends on this change, to expose capabilities from a backend. 16:05:52 ok lets get started! 16:05:57 morning 16:06:01 agenda for today 16:06:08 #link https://wiki.openstack.org/wiki/CinderMeetings#Next_meeting 16:06:13 o/ 16:06:14 #topic Replication v2 16:06:16 jgriffith: hi 16:06:25 thingee: hey 16:06:38 I unexpectedly as jgriffith to go over this with the last few comments that came in 16:06:51 So I talked to a lot of people in channel last week 16:06:51 can we un-abandon the spec ? 16:06:55 and I abandoned the spec 16:06:55 as patrickeast mentioned, when you threaten to approve something, you get feedback :) 16:07:13 #link https://review.openstack.org/#/c/155644/ 16:07:17 I can certainly turn it back on 16:07:23 and am still willing to work on it 16:07:38 jgriffith: +1 to restore it 16:07:39 but I've come to the conclusion that specs suck... or at least I suck at writing them 16:07:48 +1 16:07:57 I'd like to provide a POC of the code I have in mind to go with the spec 16:08:01 because getting feedback is hard. 16:08:09 jgriffith: sounds like other people can do the writing for you. as long as you agree with what they wrote, you can just implement it? 16:08:13 and I'd like to avoid the circular arguments that we are runnign in to 16:08:27 thingee: haha... that's one way to do it I suppose 16:08:38 but I want to be clear, it's not that i don't want to write it 16:08:46 would anyone mind helping jgriffith with the spec? 16:08:48 jgriffith: of course 16:08:55 it's that everybody raises implementation detail objections 16:09:00 thingee: It's maybe better to have the code reviewed and approved first, and then review and approve the spec:) 16:09:07 which IMHO is not the right for the spec 16:09:15 xyang1: +1000 16:09:15 :) 16:09:34 I'll work on the POC and hopefully have something for us to talk about next Wed meeting 16:09:35 xyang1, as long as that goes for everyone else in the Cinder community 16:09:42 instead of just a special few 16:09:45 I can help with spec if needed 16:09:53 hemna: +1 16:10:10 hemna: I think that was half joking 16:10:13 hemna: implementation always goes out of sync with the spec any way 16:10:14 don't get all worried 16:10:41 anyway, that's all I really have 16:10:46 so maybe while the POC code is being worked on we should put the spec in a WIP state instead of abandonded? 16:10:57 patrickeast: I'll do that now 16:10:57 jgriffith: The intention was not to derail the process. We simply need to understand how this will work for systems that only support uni-directional replication. 16:11:02 hemna: anyone can submit code before a spec. I just won't approve it. But you can always reference that to make a point that isn't easy from the spec. 16:11:19 maybe POC implementation can start in parallel with further spec refinement, but spec would still merge before code? 16:11:21 thingee, sure that's fine. I think several of us have done that. 16:11:24 jgriffith, thingee: I'm seriously proposing this change on code vs spec review 16:11:31 hemna: although, if you need the code to make your point clear in your spec, I would question your solution's complexity ;) 16:11:37 thingee, I'm just saying it needs to apply to everyone. 16:11:53 xyang1: oh.. :) 16:12:12 xyang1: honestly not a bad idea.. even if it's just gists or simple POC that goes in your won github branch 16:12:22 xyang1: probably a good topic for later 16:12:31 jgriffith: sure :) 16:12:46 jgriffith: well glad to hear this is still moving forward. 16:12:52 * jgriffith hates specs and thinks they're broken so will certainly agree with xyang1 :) 16:13:09 jgriffith, thingee: I'll propose this topic for the mid cycle meetup:) 16:13:23 thingee: +2 16:13:39 I also agree it's something to revisit. I'm just enforcing them now since that's what our current process is. I don't think we should diverge in the middle of of a release without rediscussing on fixing our process. 16:13:58 thingee: understood, we have to.. for now that's what we have 16:14:08 anything else for jgriffith ? 16:14:18 I agree that we have gotten too wrapped around the axel on some Specs. 16:14:44 ok 16:14:46 winston-d: around? 16:15:11 #action jgriffith will continue POC replication v2 code to make point in his spec 16:15:37 is anyone able to speak on cinder active/active progress? 16:15:41 specifically https://etherpad.openstack.org/p/CinderNovaAPI 16:15:55 DuncanT: ? 16:16:10 I'm not sure that's the etherpad for active/active... 16:16:20 scottda: correct this is https://etherpad.openstack.org/p/cinder-active-active-vol-service-issues 16:16:31 but we made that first etherpad a dependency to start things 16:16:56 thingee: I've got a mess of nova patches to try to make this work... it isn't proving easy. That's all the update I've got, not spent much time on it since last week 16:17:08 #topic cinder active/active 16:17:21 #link https://etherpad.openstack.org/p/cinder-active-active-vol-service-issues 16:17:49 DuncanT: is anyone else working on this with you? 16:18:34 thingee: Right now, no, since it was billed as a 'just add try/catch' so I wanted to knock up a patch. I can push to github and start working with Winston though 16:18:37 thingee, I've been helping a bit, but have just been busy the last weeks with non cinder stuff and then the nova os-brick patch 16:19:00 thingee, the first step was to get the nova bug fixed. 16:19:07 https://bugs.launchpad.net/nova/+bug/1458958 16:19:09 Launchpad bug 1458958 in OpenStack Compute (nova) "Exceptions from Cinder detach volume API not handled" [Undecided,New] - Assigned to Vilobh Meshram (vilobhmm) 16:19:15 that one 16:19:39 which is basically the try/catch stuff in Nova and dealing with the exception gracefully. that has to happen first. 16:19:54 without that, we can't really do anything in Cinder, or land anything that is. 16:19:56 hemna: I was confused by this. why is there a bug just linking to a bp? 16:20:26 thingee, vilobh's last comment in that bug ? 16:20:30 yes 16:20:39 not sure, I just noticed that myself 16:20:44 anyways, maybe winston-d will have an update for us later this week in channel. 16:20:56 well I guess the bug was specific to one case 16:21:05 #info not much progress? need update from winston-d 16:21:10 and maybe the BP is to cover the entire topic, meaning all cinder interactions. 16:21:19 * hemna is just guessing at this point. 16:21:36 #topic get volume driver capabilities 16:21:39 #link https://review.openstack.org/#/c/183947/ 16:22:06 so there has been some talk in this specs on using the glance metadata. 16:22:27 for storing the capabilities. As I've spoke in the spec, I don't think we should be storing this information 16:22:42 I do think the format which their parser to build out the GUI is pretty neat looking. 16:22:56 not sure if anyone else has seen the work that has already been done there. 16:23:07 I think the glance thing is overkill personally 16:23:39 the proposed format would look something like: 16:23:40 The Glance thing defeats the whole of the dynamic part 16:23:41 #link http://paste.openstack.org/show/281270/ 16:23:42 also, the driver capabilities can change at any time, so the glance metadata will be out of date. 16:23:45 DuncanT: +1 16:23:52 just seems like a lot of problems to introduce using that. 16:24:16 GUI example (warning video with sound): 16:24:18 #link https://youtu.be/e6MYAUzZZag?t=117 16:24:38 hemna: +1 16:24:45 so I think this maybe getting a bit ahead of ourselves. 16:25:12 The changes I made to the spec was to not really so much talk about the uses of Horizon, etc. It was just, here's the format, something can consume this. 16:25:35 thingee, +1 16:25:54 are we planning on specifying the actual keys as well that everyone needs to report ? 16:25:58 but Travis and Michal brought up is, should be folllowing a unified format so that other openstack clients can parse it easily 16:26:43 hemna: that was the separate spec I mentioned in the announcements https://review.openstack.org/#/c/150511/ 16:27:00 ok sorry. 16:27:02 thanks 16:27:16 o/ Hi 16:27:23 ok so sounds like no one cares about unified format for providing this information to clients? 16:27:26 jgriffith: ? 16:27:37 thingee: :) 16:27:55 thingee: I'm no longer arguing this one 16:28:00 lol 16:28:04 thingee: I need to choose my battles 16:28:08 So if horizon can consume that format already, and it is no less featureful than the one we invented.... 16:28:13 thingee, I'm ok with it. 16:28:31 as long as we aren't required to use the glance metadata API to store the stuff. 16:28:36 well I saw the comments from travis and michal and in my head I heard jgriffith's voice saying something along the lines of "whoa, I think we're getting ahead of the horse here" ... or something :) 16:28:41 hemna +1 16:28:55 thingee: +1 16:29:01 lol 16:29:36 :-) 16:29:39 ok, I think I got what I wanted 16:29:41 thanks :) 16:29:47 hehe 16:29:50 I'll just say again, people need to remember what makes cloud and things like AWS and GCE attractive to people 16:30:10 simplicity, abstraction and the biggest thing we seem to be missing "reliability" 16:30:18 shit should just work 16:30:21 jgriffith : +1 16:30:49 jgriffith: +1 16:30:54 #topic our current code base 16:30:57 jgriffith: hi! 16:31:04 Oh yay!! Me again :) 16:31:09 #link https://etherpad.openstack.org/p/cinder-code-cleanups 16:31:18 So I started to touch on this in the past 16:31:35 but I am hoping to maybe get some buy in on at least a few of these things 16:31:57 I've listed the things I have started picking at a little here and there 16:32:11 I'd like to see if there's interest in making a team effort to clean some of our mess up 16:32:21 jgriffith, +1 16:32:27 and I'd like to propose NO MORE big changes until we at least finish the ones we started 16:32:31 jgriffith: ++ 16:32:39 jgriffith: +1 16:32:43 jgriffith: +1 16:32:47 jgriffith: would I derail us here if I asked, what came of people picking up the taskflow clean up work that was discussed at the summit? 16:32:48 jgriffith : +1 16:32:49 Ok... so everybody says "+1" 16:32:55 how many are willign to work on it :) 16:32:58 willing 16:33:07 so it's not "fun" 16:33:13 and it's not necessarily "easy" 16:33:36 the logging one is fairly straight-forward at least 16:33:39 thingee, jgriffith: afair, dulek works on taskflow and aarefiev works on performance testing on it 16:33:40 jgriffith : I can help 16:33:49 jgriffith: I am happy to help with the logging stuff. Hope to have some people to help out as well. 16:34:01 the targets one and the others might need some input/decision on whether we stick with them or punt or what 16:34:09 jgriffith, can we file a BP on each of these items, and have folks comment in the BP on what they are going to work on? 16:34:14 but currently, all the FC stuff for example is in it's own model, the iscsi in another 16:34:23 jgriffith, we have to update our drivers to use the ABC structure. 16:34:28 and vendors are picking either the target model or dirver inheritance model 16:34:29 jgriffith: can do abc work to help mkoderer. would give me a chance to audit CI's too ;) 16:34:42 i volunteered to add hacking rules for oslo.log, but didn't finish it yet:( 16:34:57 jgriffith: I'm updating our ABC stuff, was working a bit w mkoderer on remotefs/NFS/etc. ABC 16:35:02 jgriffith, there isn't an FC target though, so the FC drivers can't migrate, FYI 16:35:02 we should update our drivers to use ABC as well 16:35:18 xyang1: +1 16:35:18 hemna: no, but I have an FC target that just inherits the base target driver 16:35:30 hemna: and uses the same design 16:35:33 am happy to consult with others as they migrate their drivers to ABC 16:35:41 hemna: IMO the design is either what we want, or it's not 16:35:49 and we should be consistent 16:35:51 jgriffith, ok maybe we can chat about that in cinder channel and I can see what I can do to help with the FC drivers. 16:35:58 hemna: the interface classes are the tricky part 16:36:05 I'm certainly not saying we should go backand change what's in already 16:36:06 remotefs was probably the worst though 16:36:07 jgriffith, I'd like to understand it a bit, then I can work on that. 16:36:19 hemna: cool 16:36:23 jgriffith: just occurred to me that the new drivers coming in for liberty should've been told about the new ABC work. 16:36:27 maybe use the 3PAR FC driver as a guinea pig. 16:36:38 thingee: yeah, that was my other gripe 16:36:50 #action thingee to update how to contribute driver documentation about the ABC stuff 16:37:00 hemna: I've got a driver that will be up hopefully later today that uses it :) 16:37:08 hemna: I need to finish it and get some testing done 16:37:09 jgriffith: :) 16:37:11 :) 16:37:16 jgriffith: gogogo! 16:37:23 jgriffith, jungleboyj : let me know if you need help regarding logging cleanup stuff… 16:37:26 the other thing is if we decide the model isn't any good we can abandon it 16:37:39 but we need to do one or the other IMO 16:37:47 vilobhmm: thanks! 16:38:00 vilobhmm: my thought was have a few folks just take a module if they have time 16:38:20 vilobhmm: The API service is the worst one right now 16:38:26 in terms of consistency etc 16:38:40 anyway... that's what I had 16:38:59 jgriffith : sure.. 16:39:03 are we going to coordinate work for these tasks on that etherpad or bp’s or ?? 16:39:15 so if i wanted to help out and sign up for some piece of this, where do i go, who do i ask? 16:39:20 patrickeast, I say BPs for each of the efforts ? 16:39:26 jgriffith: i’m guessing you are leading this effort? 16:39:47 jgriffith: I think bps might be a bit much here. just have an etherpad, person puts a name and module(s) 16:41:06 thingee : etherpads a better option IMHO 16:41:14 thingee: +1 16:41:18 ok cool 16:41:47 #link https://etherpad.openstack.org/p/cinder-log-cleanup 16:43:05 #action thingee to figure out where in the wiki to have these sort of initiatives so they're not lost 16:43:13 thingee: should we just use the one etherpad? 16:43:25 jgriffith: sure! 16:43:27 thingee: and update sections in it? 16:43:39 thingee: I only ask because I'll never be able to find all the etherpads :) 16:43:58 jgriffith: yeah was just saying I'd like to fix that. 16:44:08 ok cool 16:44:16 anything else? 16:44:19 for clean ups 16:44:40 #topic open discussion 16:45:10 a reminder to cinder reviews (not just core)... 16:45:13 #link https://etherpad.openstack.org/p/cinder-liberty-drivers 16:45:24 #info drivers that are ready for review, and what isn't 16:45:28 as I see it 16:45:34 please sign up 16:45:54 stuff is already being merged, which is great. 16:45:54 thingee: you mentioned ci auditing earlier, i was curious what our rules were for ci’s staying online… i’ve noticed lots have sort of fallen off the reviews (mines guilty of this too for periods of time while we are messing with it) 16:46:09 Should vendors add their own to the list? I'm missing from that etherpad. :( 16:46:23 earlephilhower: what is yours? 16:46:27 earlephilhower: link to review 16:47:02 thingee: https://review.openstack.org/#/c/186580/ HGST Solutions 16:47:13 BP in comments 16:47:15 thingee: Oracle iSCSI CI is now working. Is it possible to move it to the "ready" section? 16:47:19 patrickeast: I don't really have any I guess. Just looking to see if they're running at all. we probably should talk about next steps of expecting from CIs at this point 16:47:37 patrickeast: at least for vendors that have had periods to make improvements and understand their ci's 16:47:57 diemt: I'm waiting for a period for the CI to be running stable 16:48:07 does my driver need to be on that list to stay in liberty? 16:48:15 thingee: patrickeast I'd propose we all look at subunit reports 16:48:27 thingee: patrickeast I can be a test for that 16:48:43 thingee: patrickeast and see if folks want to voluntarily follow suit? 16:48:52 jgriffith: seems reasonable 16:48:53 thingee: It has been running since 6/8. Could you let me know how long it has to be stable to be moved? 16:48:58 Swanson: the list is only for new drivers 16:49:31 xyang1: thanks. that's what I thought but best to check. :) 16:49:39 thingee: patrickeast something along the lines of this: https://review.openstack.org/#/c/183696/4/doc/source/graph-count.png 16:49:44 earlephilhower: I'll take a closer look 16:49:46 jgriffith: thingee: i guess one thing that concerns me is that i don’t know what kind of uptime i need or *when* it needs to be working to avoid having a driver potentially removed… we kind of have this threat of they need a ci working to stay in tree 16:49:54 or better: https://review.openstack.org/#/c/183696/4/doc/source/graph-failures.png 16:50:00 but not really defined exact rules on when things would be removed 16:50:15 patrickeast: I'm working on collecting some data 16:50:19 thingee: Thx 16:50:24 jgriffith: oo nice graphs 16:50:26 patrickeast: and we can kidna figure out what we think after that 16:50:42 patrickeast: without the data I don't think we want to make too many decisions :) 16:50:53 jgriffith: sounds good 16:50:56 there was some forward progress (i think) in the ci working group earlier as far as a dashboard for ci's 16:50:56 I think it's going to be surprising for some 16:51:00 maybe that will help too 16:52:13 alright thanks everyone 16:52:16 #endmeeting