16:00:22 <jgriffith> #startmeeting cinder
16:00:22 <openstack> Meeting started Wed Jan  8 16:00:22 2014 UTC and is due to finish in 60 minutes.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:26 <openstack> The meeting name has been set to 'cinder'
16:00:27 <jgriffith> Hey everyone
16:00:30 <avishay> hello!
16:00:30 <duncanT-mob> hi
16:00:39 <rushiagr2> o/
16:00:41 <kmartin> hello
16:00:42 <eharney> hi
16:00:55 <jgriffith> welcome back and happy new year (for those that took vacation)
16:01:09 <jgriffith> I tink we can keep this short
16:01:15 <rushiagr> yay! happy new year to all!
16:01:19 * caitlin56 waves
16:01:25 * jgriffith laughs and recalls saying that EVERY meeting
16:01:39 <rushiagr> haha
16:01:46 <avishay> haha
16:01:51 <jgriffith> Ok.. pretty good turn out, let's get on with it
16:01:52 <kenhui1> happy new year everyone!
16:02:00 <jgriffith> #topic I-2 status
16:02:12 <jgriffith> https://launchpad.net/cinder/+milestone/icehouse-2
16:02:28 <jgriffith> We're falling a bit behind in keeping up with things here
16:02:54 <bswartz> hi
16:02:55 <jgriffith> Keep in mind that the time to get through the gates is pretty long right now, and next week is going to be even worse if history serves us
16:03:19 <jgriffith> If you have a BP you're working on here please try to get things submitted this week if possible
16:03:24 <avishay> yep...gate is pretty ridiculous
16:03:39 <jgriffith> also, please touch base with me if you have any doubt at all about making the deadline
16:04:02 <jgriffith> avishay: yeah :(
16:04:18 <bswartz> we are victims of openstack's success?
16:04:20 <kmartin> i'll have Jim Branan update his BP, the new Lefthand Driver, is in review
16:04:31 <jgriffith> I read back on the proposal for Ollie's bp on the metadata...
16:04:36 <jgriffith> I think it was Ollie's...
16:04:49 <jgriffith> and I think I understand better what you all were getting at
16:05:03 <jgriffith> not sure if dosaboy or ollie is working it
16:05:03 <duncanT-mob> :-)
16:05:18 <duncanT-mob> I think Ollie is
16:05:26 * jgriffith prposes we ban the label "metadata" :)
16:05:30 <jgriffith> K
16:05:43 <duncanT-mob> Probably not a bad plan
16:05:44 <avishay> :)
16:05:48 <jgriffith> I'll see if I can get a hold of him later to see what the status is
16:06:13 <jgriffith> duncanT-mob: How's your bp coming along?
16:06:29 <jgriffith> https://blueprints.launchpad.net/cinder/+spec/filtering-weighing-with-driver-supplied-functions
16:06:48 <duncanT-mob> I'd have a patch up now if I wasn't it of the country
16:06:58 <jgriffith> ha :)
16:07:02 <duncanT-mob> Will get it in this week
16:07:06 <jgriffith> You on for the 23'rd?
16:07:07 <jgriffith> Ok
16:07:11 <duncanT-mob> Friday probably
16:07:12 <jgriffith> I'll leave it targetted then
16:07:20 <jgriffith> Just let me know if you want to bump it to I3
16:07:20 <duncanT-mob> cheers
16:07:28 <jgriffith> earlier is better than later to bump
16:07:57 <jgriffith> kmartin: do you know anything about your comrads doing the MSA driver?
16:08:17 <jgriffith> https://blueprints.launchpad.net/cinder/+spec/add-msa-2040-driver
16:08:25 <kmartin> no, this is some firm in France doing this work
16:08:38 <jgriffith> kmartin: ohh... one of those deals
16:08:47 <jgriffith> ok
16:09:04 <jgriffith> guess I could've figured that "objectif libre"
16:09:06 <jgriffith> Ok
16:09:28 <jgriffith> I'm going to push out the items that are not started to I3
16:09:36 <jgriffith> at this point there's little chance of:
16:09:40 <jgriffith> 1. getting through reviews
16:09:44 <jgriffith> 2. getting through gates
16:10:01 <jgriffith> if things are not moving along I see little chance of making it
16:10:08 <jgriffith> velocity is not what it used to be
16:10:22 <jgriffith> any objections/ammendments to that?
16:10:42 <coolsvap> jgriffith:  I would like to discuss multi-volume-create, maybe in open discussion
16:11:01 <jgriffith> coolsvap: we can do that... I'll give you the floor at the end
16:11:10 <duncanT-mob> Pushing out anything not started makes sense
16:11:12 <jgriffith> Ok.. anything else on I-2 that people want to bring up?
16:11:21 <jgriffith> I"m going to talk about reviews next :)
16:11:36 <rushiagr> jgriffith: I'd like to expose volume types via the EC2 API
16:11:47 <rushiagr> jgriffith: but is that a part of Cinder meeting?
16:11:52 <jgriffith> rushiagr: we can talk later
16:11:56 <rushiagr> jgriffith: sure
16:12:05 <jgriffith> rushiagr: Not sure if you saw my comments on your patch and email
16:12:15 <duncanT-mob> I guess reviews have been slow with vacation
16:12:17 <rushiagr> jgriffith: saw it
16:12:27 <jgriffith> Let's talk about reviews.. rushiagr we'll get back to that
16:12:31 <jgriffith> #topic reviews
16:12:32 <rushiagr> jgriffith: sure
16:12:48 <jgriffith> I've tried this before but I want to try again
16:13:02 <jgriffith> Given I2 is just around the corner
16:13:11 <jgriffith> and it's hard to get things reviewed and through the gates...
16:13:12 <kmartin> avishay: is volume retype going to land in I2? or has it already.
16:13:24 <avishay> kmartin: just went in
16:13:29 <jgriffith> I'd like for everybody to be diligent about reviewing the items that are slated for I2
16:13:37 <kmartin> avishay: cool
16:13:56 <jgriffith> The one line typo fixes and removing copyright headers from init files is really not important right now IMO
16:14:04 <jgriffith> it clutters the review queue and the gate
16:14:22 <duncanT-mob> agreed
16:14:28 <winston-d> jgriffith: +1
16:14:30 <avishay> yep
16:14:31 <jgriffith> I'd ask everybody to use https://launchpad.net/cinder/+milestone/icehouse-2 as a guide for what to review
16:14:32 <rushiagr> point noted
16:14:53 <jgriffith> We have a number of targeted Medium BP's that need reviews
16:15:01 <avishay> also doing 'recheck' once is enough...i think it's pretty clear when jenkins fails for real
16:15:04 <jgriffith> and the bugs should go without saying
16:15:10 <jgriffith> avishay: :)
16:15:50 <jgriffith> If you submit a patch and I -2 it because it's something non-prioritized don't feel bad :)
16:16:12 <jgriffith> I want to do everything we can to keep non-essential patches from going in to the gate queue
16:16:30 <thingee> hi folks
16:16:36 <avishay> thingee: yo
16:16:43 <jgriffith> thingee: hola
16:16:54 <jgriffith> anyway.. the -2 approach is drastic and shouldn't be necessary
16:17:06 <jgriffith> but it's going to require all of us to be diligent
16:17:53 <jgriffith> Ok.. anybody have anything else on reviews?
16:18:34 <jgriffith> alright let's talk about some easy stuff...
16:18:50 <jgriffith> #topic alternatiing meeting times proposal feedback
16:19:01 <rushiagr> -1
16:19:15 <jgriffith> I sent an email out to the dev list on this and it seems like maybe trying to solve a problem that doesn't exist
16:19:17 <kmartin> I would prefer to keep the current time
16:19:37 <bswartz> +1 keep the current time
16:19:43 <jgriffith> Yeah, the majority of the feedback even from the folks in distant TZ's was that they were fine with how we're doing it now
16:19:45 <avishay> +1 current time
16:19:50 <glenng> +1 current time
16:19:59 <thingee> well that was easy
16:20:02 <duncanT-mob> current time suits me
16:20:06 <kmartin> +1 current
16:20:07 <rushiagr> I'd prefer _one_ time. I keep forgetting with this single time. Two timings will make me miss almost all of them
16:20:07 <xyang1> +1 current time
16:20:10 <jgriffith> I think we all have a tendency to be around IRC outside of our TZ's so I think we're doing ok
16:20:23 <jgriffith> alright, that issue is closed then
16:20:27 <avishay> it's hard enough remembering daylight savings :)
16:20:30 <jgriffith> we'll keep our regular weekly meeting and time
16:20:32 <winston-d> 1600 UTC works for me
16:20:37 <jgriffith> avishay: no doubt!!
16:20:43 <kmartin> I bet the people that want to change it aren't here due to the time :)
16:20:56 <jgriffith> winston-d: you were really the only person that I knew that was doing the middle of the night thing to make this meeting ;)
16:21:06 <jgriffith> kmartin: yeah, that's true
16:21:08 <avishay> kmartin: :)
16:21:09 <rushiagr> heh
16:21:14 <bswartz> avishay: MS exchange understands UTC and sends reminders appropriately
16:21:18 <jgriffith> kmartin: but even on the ML I didn't get much response in favor of it
16:21:35 <avishay> bswartz: i don't know what that is ;)
16:21:37 <winston-d> jgriffith: :) it may such a little bit more for ppl from Japan and Korea
16:21:38 <jgriffith> bswartz: linux let's you just set your system clock to UTC and :
16:21:48 <winston-d> s/such/suck
16:21:49 <jgriffith> winston-d: true
16:22:18 <jgriffith> winston-d: I think I'm going to have an "office hour" or something to be available certain nights of the week
16:22:24 <jgriffith> if people want to connect they can
16:22:35 <avishay> nice idea
16:22:42 <jgriffith> but I am around late at night here anyway, and I rarely run into anybody but winston-d duncanT-mob and avishay
16:22:49 <jgriffith> and rushiagr
16:23:06 <jgriffith> anywho... I think we can close that one for now and move along
16:23:20 <jgriffith> #topic driver cert script
16:23:36 <jgriffith> Didn't get any feedback on my ML posting
16:23:58 <jgriffith> So I'm going to take the feedback from kmartin and others via IRC and put a process proposal together
16:24:07 <avishay> jgriffith: oops sorry about that, slipped my mind
16:24:19 <winston-d> jgriffith: what was the topic of the thread?
16:24:23 <jgriffith> in the meantime...  there's no reason you couldn't/shouldn't be running your drivers through the test
16:24:27 <avishay> jgriffith: i liked what walt said on the ML
16:24:48 <jgriffith> winston-d: http://lists.openstack.org/pipermail/openstack-dev/2013-December/022925.html
16:25:09 <winston-d> jgriffith: thx
16:25:41 <jgriffith> It would be great if you have a chance to run it to do so, I'm sure there are improvements that can be made bugs to fix but it's no fun running it over and over on just my systems :)
16:26:01 <jgriffith> and I know there are bugs in some of the drivers that this will find :)
16:26:28 <jgriffith> Ok... 25 minutes
16:26:33 <jgriffith> that's all the booring stuff
16:26:41 <jgriffith> #topic multi-create
16:26:51 <jgriffith> coolsvap: go for it
16:27:09 <coolsvap> jgriffith:  thanks
16:27:11 <coolsvap> hello all
16:27:16 <avishay> hi
16:27:35 <winston-d> hi
16:27:52 <coolsvap> I would like to get things clear on  https://blueprints.launchpad.net/cinder/+spec/create-multiple-volume-from-cli
16:28:52 <coolsvap> 1. Should it be only in cinderclient or should it have cinder-api changes as well?
16:29:01 <avishay> this looks good to me.  might want to make a prefix for the name and append a number?
16:29:08 <avishay> i would say definitely cinderclient only
16:29:09 <guitarzan> are we voting? :)
16:29:23 <jgriffith> client only
16:29:24 <eharney> i haven't seen a good argument yet for why we would want to do it in the API
16:30:05 <rushiagr> I guess the only point in api's favour is one api call instead of many
16:30:06 <winston-d> one argument coolsvap has is Horizon doesn't use cinder client
16:30:26 <caitlin56> Are these all being created on a single backend target, or wherever? The latter favors doing this as a client-only solution.
16:30:42 <duncanT-mob> Then horizon can use a for loop...
16:30:42 <jgriffith> however horizon can contain the code to do the looping calls itself
16:30:44 <guitarzan> winston-d: really?
16:30:49 <jgriffith> duncanT-mob: :)
16:30:51 <guitarzan> horizon has its own client code?
16:30:58 <eharney> i agree w/ duncanT...
16:30:59 <winston-d> guitarzan: i'm not sure, coolsvap said so.
16:31:05 <coolsvap> winston-d:  I think i should take the argument
16:31:07 <guitarzan> that's crazy :)
16:31:15 <xyang1> Horizon uses cinder client
16:31:27 <winston-d> xyang1: ahha!
16:31:37 <caitlin56> Even if it did not, that would be something for Horizon to fix.
16:31:37 <guitarzan> phew
16:31:51 <winston-d> cinder client +1
16:32:03 <jgriffith> coolsvap: you good with that?
16:32:41 <xyang1> this is from horizon code: from cinderclient.v1 import client as cinder_client
16:32:46 <jgriffith> caitlin56: it would seem silly for horizon to not use the clients wouldn't it.
16:33:22 <caitlin56> jgriffith: yes, so if they had been that silly we should not have accomodated thier silliness.
16:33:29 <jgriffith> caitlin56: indeed
16:33:44 <coolsvap> jgriffith:  yeah kind of, currently I dont have any argument rather than third party client would help with api changes
16:34:02 <jgriffith> coolsvap: I think the feature works fine in the client
16:34:12 <jgriffith> coolsvap: it's a clean non-disruptive change that way as well
16:34:17 <coolsvap> jgriffith:  yes, it does
16:34:23 <jgriffith> Ok.. great
16:34:29 <jgriffith> rushiagr: you're up
16:34:33 <winston-d> i even got feedback from end users that they would like to have a single API to do multiple instances using BFV. :)
16:34:34 <coolsvap> 2. It would be only V2 change
16:34:36 <jgriffith> #topic volume-types in ec2
16:34:38 <coolsvap> just a min
16:34:44 <jgriffith> doh!
16:34:46 <rushiagr> coolsvap: sure, take ur time
16:34:59 <rushiagr> jgriffith: I can wait, we have loads of time today :)
16:35:19 <coolsvap> 2. It would be only cinderclient V2 change, or should go in both v1 & v2?
16:35:25 <jgriffith> V2 only
16:35:33 <jgriffith> V1 is maintenance only
16:35:36 <jgriffith> bugs
16:35:38 <jgriffith> no new features
16:35:41 <avishay> finally :)
16:35:45 <coolsvap> jgriffith:  okay
16:35:46 <jgriffith> avishay: indeed
16:36:07 <coolsvap> 3. jgriffith: target-milestone?
16:36:08 <winston-d> but actually, this has nothing to do with the API version, right?
16:36:14 <guitarzan> right
16:36:26 <jgriffith> coolsvap: I'd prefer this wait until I3 opens up
16:36:39 <jgriffith> Based on my rant about priority/critical patches earlier :)
16:36:49 <duncanT-mob> I3, purely to get eyes on it
16:36:49 <coolsvap> yup, sure
16:36:49 <jgriffith> winston-d: DOH
16:36:54 <jgriffith> you're correct
16:37:16 <coolsvap> jgriffith:  I had same discussion with winston-d earlier
16:37:24 <avishay> winston-d: true
16:37:32 <coolsvap> so just wanted to bring it up here
16:37:42 <jgriffith> Oh, so you guys are formulating a plan eh :)
16:38:11 <jgriffith> frankly I suppose I don't care
16:38:23 <jgriffith> I'd like to see us stop carrying everything back to V1
16:38:24 <winston-d> jgriffith: nah, just answering some questions coolsvap has
16:38:28 <jgriffith> even if it is just the client
16:38:36 <jgriffith> winston-d: :)  I'm kiddin
16:38:47 <winston-d> jgriffith: i know. :)
16:39:00 <jgriffith> but I can see people getting tweaked about not having this as it's just a client feature
16:39:13 <jgriffith> I really have no opinion, I'll leave it to the rest of the team
16:39:17 * jgriffith passed the buck
16:39:47 <duncanT-mob> Pass another couple and I'll be able to get a coffee...
16:40:00 <jgriffith> duncanT-mob: drinks the fancy stuff
16:40:25 <duncanT-mob> Nah, I'm in a train station... just high proceed stuff Sally
16:40:35 <jgriffith> LOL
16:40:41 <duncanT-mob> *sadly
16:41:01 <avishay> ahh autocorrect is great
16:41:05 <rushiagr> :D
16:41:09 <jgriffith> Ok.. coolsvap can we move on, or you got more?
16:41:34 <coolsvap> jgriffith:  I think I will take it as yes for both V1 & V2 since winston-d & jgriffith
16:41:36 <coolsvap> no I am done!
16:41:46 <jgriffith> alrighty...
16:41:52 <jgriffith> rushiagr: types in ec2
16:42:00 <jgriffith> convince me :)
16:42:01 <coolsvap> rushiagr:  thanks!
16:42:12 * rushiagr searches for the blueprint
16:42:19 <rushiagr> blueprints.launchpad.net/nova/+spec/ec2-volume-type
16:42:58 <rushiagr> I created this after I saw your thoughts on the review and the bug
16:43:10 <jgriffith> :)
16:44:00 <avishay> rushiagr: so this is for someone using the EC2 API to talk to openstack?
16:44:04 <rushiagr> apart from this, I'm also trying to expose volume metadata as EC2 'tags', as in https://review.openstack.org/#/c/64690/
16:44:06 <rushiagr> avishay: yep
16:44:31 <rushiagr> so just wanted to seek any feedback, and any suggestions if someone has a better way
16:44:43 <jgriffith> kill ec2 api :)
16:44:48 <avishay> i'm assuming people are doing this because you are taking care of this, but ...uch...
16:44:51 <duncanT-mob> Seems reasonable, though what happens when amazon add more types? can we make the config option a map or dictionary and be done with it?
16:45:15 <jgriffith> the bigger problem is what happens when you have multiple types/backends that do qos
16:45:22 <avishay> amazon should change their API to be openstack compatible :)
16:45:30 <jgriffith> avishay: +1000
16:45:59 <rushiagr> haha
16:46:05 <jgriffith> One problem I have with this is we've punted patches in the past that tried to implement default types
16:46:09 <jgriffith> remember encryption
16:46:23 <jgriffith> we pretty much raked them over the coals for trying to do that
16:46:42 <jgriffith> and if the type isn't implemented then what?
16:47:20 <rushiagr> jgriffith: you mean to say no default type, only allow it when admin manually configures?
16:47:32 <jgriffith> rushiagr: yeah
16:47:43 <jgriffith> rushiagr: so what you could maybe do....
16:47:55 <jgriffith> keep all the changes in the ec2 code only
16:48:11 <avishay> this is sounding good :)
16:48:13 <jgriffith> Then have an extra-spec key that indicates io1 support
16:48:23 <winston-d> rushiagr: yeah, not default type, you have to consider those existing cinder deployment
16:48:24 <jgriffith> then nova/ec2 can display the type in it's code
16:48:27 <jgriffith> for all of them
16:48:42 <jgriffith> In other words it's all smoke an mirrors in the ec2 code
16:48:45 <duncanT-mob> jgriffith +1
16:48:57 <rushiagr> hmmm
16:49:00 <jgriffith> that maybe what you had in mind but I think it's the way to go
16:49:07 <duncanT-mob> Actually you could use a tag for the standard one too
16:49:16 <jgriffith> I mean, the ec2 layer in nova is just another abstraction :)
16:49:24 <jgriffith> duncanT-mob: indeed
16:49:26 <rushiagr> true
16:49:50 <jgriffith> duncanT-mob: but I was just thinking "standard" is the default/any volume that doesn't have a cinder-type extra-spec
16:50:14 <duncanT-mob> that would require less config, true
16:50:21 <jgriffith> and actually, If I were the admin I'd create a scoped key
16:50:23 <rushiagr> is 'extra-spec' just metadata? or something else? I'm sorry, I have never looked into what exactly is extra spec
16:50:30 <jgriffith> "EC2:blah"
16:50:40 <jgriffith> rushiagr: yes, just metadata
16:50:42 <jgriffith> k/v pairs
16:50:56 <jgriffith> so in cinder an admin coud do:
16:50:59 <jgriffith> type-create foo
16:51:07 <bswartz> (11:05:24 AM) ***jgriffith prposes we ban the label "metadata" :)
16:51:16 <duncanT-mob> Specifically volume type metadata... since we have so much metadata
16:51:19 <jgriffith> extra-specs foo set ec2:io1:True
16:51:21 <jgriffith> or whatever
16:51:28 <jgriffith> bswartz: ;)
16:51:36 <rushiagr> ohh, I get it
16:51:42 <jgriffith> Nova can easily look at this info
16:51:58 <duncanT-mob> scoped keys +1
16:52:22 <rushiagr> this sounds good
16:52:22 <winston-d> didn't know extra spec can do this much. :)
16:52:38 <jgriffith> and the nova ec2/api can be smart and "look" for that type before going throught eh create and give feedback "notsupported" or whatever
16:52:43 <rushiagr> duncanT-mob: not sure what are scoped keys. I hope you meant volume-type extra specs?
16:52:48 <jgriffith> winston-d: :)
16:53:04 <jgriffith> winston-d: the biggest problem with extra-specs is it can do too much :)
16:53:07 <duncanT-mob> rushiagr: yes
16:53:35 <jgriffith> rushiagr: so it's like this...
16:53:50 <jgriffith> regular keys==>  'key' = 'value'
16:53:53 <rushiagr> duncanT-mob: ok
16:54:06 <jgriffith> scoped keys===>  'scope:key' = 'value'
16:54:22 <jgriffith> so that leading "scop:" I added to the key is an identifier
16:54:34 <jgriffith> a sort of heirarchal classification
16:54:40 <rushiagr> jgriffith: got it
16:54:42 <rushiagr> jgriffith: thanks
16:54:46 <jgriffith> kinda like "do I even care about this key or not"
16:54:50 <rushiagr> I like the idea
16:54:54 <jgriffith> or what's it's contexst
16:54:57 <jgriffith> context
16:54:58 <jgriffith> Ok... cool
16:55:06 <jgriffith> So you'll need to be clever
16:55:14 <rushiagr> i'll play around it and update the bp
16:55:27 <jgriffith> but it's doable and it should be a clean add
16:55:30 <winston-d> rushiagr: make sure don't use the 'capabilities' as scope key, it's reserved for capabilities requirement meant to be consumed only by scheduler
16:55:32 <rushiagr> thanks for the feedback people
16:55:36 <caitlin56> jgriffith:it is really an interface solution, because the context is being prepended to the keys providedby default.
16:55:37 <jgriffith> rushiagr: let me know if you would like/need help
16:55:45 <jgriffith> caitlin56: exactly
16:55:50 <rushiagr> winston-d: point noted
16:55:54 <jgriffith> rushiagr: I'm painfully familiar with that code :)
16:56:03 <rushiagr> jgriffith: heh, thanks
16:56:09 <jgriffith> alrighty folks...
16:56:14 <jgriffith> #topic open-discussion
16:56:20 <jgriffith> anything else anybody has?
16:56:27 * jgriffith notices once again it wasn't a short meeting :(
16:56:41 <rushiagr> but we're on time! :)
16:56:43 <jgriffith> but I think it was productive at least :)
16:56:52 <jgriffith> rushiagr: and indeed we're not late this time (yet)
16:57:17 <duncanT-mob> mobile battery nearly dead, I'm off. Bye all
16:57:20 <jgriffith> Ok, everybody... thanks a bunch
16:57:22 <avishay> DuncanT-1: bye
16:57:25 <avishay> duncanT-mob: bye
16:57:26 <jgriffith> duncanT-mob: thanks for doing the mobile version
16:57:37 <rushiagr> duncanT-mob: o/
16:57:42 <avishay> bye all!
16:57:42 <jgriffith> everybody hang in there for I2, keep up on reviews etc
16:57:45 <jgriffith> and thanks!!!!
16:57:52 <avishay> jgriffith: thanks
16:57:58 <jgriffith> #endmeeting