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