16:13:58 <jgriffith> #startmeeting cinder
16:13:58 <openstack> Meeting started Wed Oct 24 16:13:58 2012 UTC.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:13:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:14:00 <openstack> The meeting name has been set to 'cinder'
16:14:13 <jgriffith> Sorry for my tardiness
16:14:50 <jgriffith> have an agenda here: http://wiki.openstack.org/NovaVolumeMeetings
16:15:05 <jgriffith> let's get started
16:15:10 <jgriffith> #topic Blue Prints
16:15:24 <jgriffith> We had some really good ideas come out of the summit
16:15:40 <jgriffith> Over the course of the week I'd like to get these things transferred into blue-prints if we could
16:15:55 <jgriffith> Then I can start going through and targetting against milestones
16:16:20 <winston-d> sounds good
16:16:22 <jgriffith> Some folks have already started (thank you) but there's a lot to add and I don't want to do it all myself :)
16:16:50 <jgriffith> All of the etherpads are accessible via http://wiki.openstack.org/Summit/Grizzly/Etherpads
16:17:10 <jgriffith> So grab your topics and start proposing if you could please!
16:17:20 <jgriffith> I'd also like to see something more on island
16:17:49 <rongze> https://github.com/freedomhui/cinder/
16:17:58 <jgriffith> rongze: Excellent!  thanks
16:18:02 <rongze> island is shared in github
16:18:16 <rongze> But it have more work to do....
16:18:41 <jgriffith> We should probably plan on spending some time picking through it with the Rax and HP folks and see what we come up with
16:19:08 <jgriffith> and of course anybody else that's interested, I just know there is some overlap between those groups
16:19:41 <jgriffith> Ok, DuncanT rnirmal if you get a chance to take a swag at your BP's that would be great
16:19:55 <jgriffith> I'll hit up cthier and clayg when I see them
16:19:59 <rnirmal> jgriffith: will do
16:20:05 <rnirmal> they will be a little busy this week
16:20:10 <jgriffith> :)
16:20:14 <jgriffith> figured as much
16:20:23 <jgriffith> I'll try to grab there's for them probably
16:20:41 <jgriffith> Probably lump the API stuff all into one BP
16:20:46 <jgriffith> we'll see
16:21:17 <rnirmal> we need to decide may be next meeting... on how we are going to manage multiple api versions
16:21:17 <jgriffith> Alright, any questions on the etherpad->blue-print work?
16:21:21 <DuncanT> I'll find ours and see how up-to-date they are
16:21:50 <jgriffith> rnirmal: yup, there's some precedence set that we can use as a guide I think though
16:22:09 <thingee> rnirmal: I've been looking into it. personally I like glance's approach.
16:22:12 <jgriffith> DuncanT: thanks!
16:22:22 <jgriffith> thingee: +1
16:22:30 <rnirmal> thingee: that's good.. since I didn't like the nova approach so much
16:22:36 <thingee> v1 v2 directory, separate wsgi controllers and routes in each dir
16:23:06 <thingee> or v1.x....whatever you guys agree for version number :)
16:23:10 <jgriffith> thingee: I'd like to model alot of the API stuff we do after Glance IMO
16:23:17 <creiht> oh hai :)
16:23:33 <jgriffith> thingee: That's where I started with the volume.class api stuff etc
16:23:37 <jgriffith> creiht: hola!
16:23:47 <creiht> sorry... been a bit busy :)
16:24:00 <jgriffith> creiht: Just finishing up on my pleas to convert our summit etherpads to bp's
16:24:03 <creiht> I hope to start going through the api stuff next week and start making bugs/blueprints
16:24:10 <jgriffith> creiht: understood... and congratulations :)
16:24:24 <creiht> thanks! and yeah... been a bit busy :)
16:24:34 <jgriffith> creiht: sounds good... some us can help as well and work off of the etherpad if you like
16:24:41 <creiht> cool
16:24:48 <thingee> I've been learning a lot in stepping through glances flow for this. I've successfully gotten requests to go to separate controllers, but I don't want to be holding back development since everyone needs this
16:25:49 <thingee> I was working on this over the summit, but haven't spent time since cause of the craziness of this month for myself.
16:25:50 <jgriffith> thingee: I don't think you'd be holding anything back at all.  If you have the time to keep working on it and share your ideas (as far as the seperation etc)
16:26:11 <jgriffith> that would be great because it will probably be a week or two before we're ready to tackle the API changes
16:26:30 <jgriffith> errr... what I mean is as far as adding the *new* stuff
16:26:53 <jgriffith> thingee: make sense?  Or am I incoherrent?  :)
16:27:29 <thingee> crystal clear! ok, how about we plan to have a framework of the separation of the apis to be available with v1 still intact of course.
16:27:41 <thingee> we = me and whoever wants to help!
16:27:51 <jgriffith> thingee: Yup, I believe we have to provide that
16:28:07 <jgriffith> thingee: and yes, I would hope we can get a couple of folks helping you on this
16:28:25 <jgriffith> Alright... shall we move on to NFS?
16:28:28 <thingee> v2 will also include taking out that still exception that gives 500 errors for everything. I'll be adjusting tests according to expect real helpful errors too
16:28:41 <jgriffith> thingee: assumed :)
16:28:41 <thingee> or v1.x...what am I calling this thing heh
16:29:10 <jgriffith> thingee: I would like to do v2 personally
16:29:24 <jgriffith> thingee: Then do incrementals after Grizzly
16:29:34 <thingee> sounds fine to me
16:29:39 <woodspa> Before we move on who is driving the QoS work?
16:30:00 <jgriffith> woodspa: I think we need to sort some more out on that
16:30:27 <jgriffith> woodspa: The general feel seemed to be that we could/should deal with that via volume_type/extra_specs
16:30:40 <jgriffith> woodspa: But not sure if we were really clear there or not?
16:30:53 <jgriffith> Let's add it as a discussion point later if we have time ok?
16:31:02 <woodspa> sounds good
16:31:12 <jgriffith> alright...
16:31:17 <jgriffith> #topic NFS
16:32:00 <jgriffith> bswartz: Hope I wasn't too much of a PITA on this
16:32:16 <bswartz> no, your concerns are totally understandable
16:32:29 <jgriffith> bswartz: cool
16:32:36 <bswartz> by "NFS" do you mean the whole NAS thing? or the NFS drivers?
16:32:48 <jgriffith> bswartz: The whole NFS proposal
16:32:52 <bswartz> because the NAS enhancements cover both NFS and CIFS
16:33:01 <jgriffith> Ok.. sorry NAS
16:33:08 <bswartz> although only crazy people use CIFS
16:33:10 <DuncanT> FSaaS
16:33:13 <jgriffith> BTW, that doesn't help alleviate my concerns :)
16:33:19 <jgriffith> DuncanT: +1
16:33:44 * jgriffith updated the meeting page :)
16:33:57 <bswartz> I realized that the link I provided in my etherpad was to the wrong branch
16:34:06 <bswartz> there 's another branch that does work in devstack
16:34:11 <jgriffith> bswartz: ahh... cool
16:34:22 <bswartz> and we'll be keeping it up to date and making a submission soon
16:34:30 <bswartz> my dev team is on vacation this week, unfortunately
16:34:49 <jdurgin> could you add the etherpad links to the wiki?
16:34:53 <jgriffith> So my concerns are still there, but I don't want to dominate the conversation on this
16:35:19 <bswartz> jgriffith: at the conference you alluded to some ideas that might make the submission less objectionable
16:35:23 <jgriffith> bswartz: Yes, I'd like to see the etherpad added to the summit etherpad page and the updated github links
16:35:40 <jgriffith> bswartz: Yes, but I'm still concerned about the scope and added work
16:35:49 <jgriffith> bswartz: Take a look at the current bug list :(
16:36:00 <DuncanT> I'd also suggest we want some input from the lustre guys trying ot do the same thing, see if the two approaches mesh
16:36:11 <jgriffith> actaully... I was going to suggest:
16:36:27 <jgriffith> Sending an email out to the user and dev list
16:36:36 <jgriffith> I'd like to get more community input on this
16:36:43 <bswartz> I'm going to get one of the developers on my team to join cinder core
16:36:45 <jgriffith> Are we trying to solve a *real* problem
16:37:05 <bswartz> and try to help with more things than just netapp stuff
16:37:19 <jgriffith> bswartz: that would be very helpful
16:37:32 <jgriffith> bswartz: Thoughts on the ML proposal?
16:37:41 <jgriffith> or anybody else have thoughts on that?
16:37:53 <bswartz> fwiw, a lot of people came up to me at the conference and said they our idea was a good one
16:38:09 <jgriffith> bswartz: fair
16:38:24 <jgriffith> so does that == "no" on the ML proposal?
16:38:29 <bswartz> jgriffith: I think sending out something to the mail list would be beneficial, but I'm not sur what I would expect the happen as a result
16:38:40 <winston-d> i like the ML idea.
16:38:55 <bswartz> I'll go ahead and do it
16:39:14 <jgriffith> bswartz: thank you!
16:40:11 <bswartz> so someone mentione lustre?
16:40:31 <winston-d> duncan did
16:40:33 <bswartz> I wasn't aware they were interested in NAS support in cinder
16:40:49 <DuncanT> There were a bunch of lustre guys at the summiting looking at FSaaS too... I'll ping you if I can find some contact details
16:40:51 <bswartz> or did I misunderstand?
16:40:59 <bswartz> okay thanks
16:41:17 <DuncanT> It wasn't quite NAS but close enough that you guys should talk I think
16:41:18 <jgriffith> Ok, any other thoughts on FSaaS?
16:41:31 * jgriffith thinks the name alone excludes it from BSaaS :)
16:41:33 <bswartz> not from me
16:41:43 <bswartz> haha
16:42:00 <jgriffith> Sorry.... couldn't resist :)
16:42:03 <winston-d> bswartz, do we need anything special fro celiometer for NAS?
16:42:08 <jgriffith> Alrighty...
16:42:21 <bswartz> winston-d: I would expect that to come later
16:42:45 <winston-d> ok
16:42:54 <bswartz> winston-d: my first guess is that it would be much harder to do, unless we take advantage of hypervisor-based file-sharing technology
16:43:26 <jgriffith> Ok, let's move along if there are no objections
16:43:33 <winston-d> sure.
16:43:34 <bswartz> but some customers will have no interest in that
16:43:43 <bswartz> yes let's move on
16:43:51 <jgriffith> #topic Fibre-Channel
16:44:01 <kmartin> jgriffith: I'm here from HP and we have a meeting setup with the Brocade guys and us to decide if we want one blue print or two for FC. I suspect by next weeks meeting we would have one submitted
16:44:08 <jgriffith> kmartin: Yay!
16:44:23 <jgriffith> One please :)
16:44:34 <jgriffith> Unless they cover different aspects
16:44:48 <woodspa> kmartin: Did you connect with Dietmar Noll from IBM too?
16:44:55 <jgriffith> kmartin: The sooner the better
16:45:16 <kmartin> yes I believe so Andre is setting up the meeting
16:45:23 <jgriffith> kmartin: This is another one that I believe the scope is going to be more significant than what some initially may believe
16:45:32 <kmartin> I agree
16:45:45 <jgriffith> kmartin: So I'd like to get the ball rolling as soon as possible
16:45:57 <jgriffith> kmartin: Keep in mind the implications for nova as well
16:46:33 <kmartin> ok...that's the plan, I believe the meeting is schedule for this friday
16:46:44 <jgriffith> excellent... keep me posted if you can
16:46:50 <kmartin> will do
16:47:12 <jgriffith> kmartin: ping zykes- if you get a chance too
16:47:28 <jgriffith> kmartin: He's been asking me about FC support so may have some helpful input
16:47:33 <kmartin> ok
16:47:45 <jgriffith> alright... anything else on Fibre-Channel?
16:48:09 <jgriffith> #topic bugs
16:48:22 <jgriffith> https://bugs.launchpad.net/cinder/+bugs?orderby=status&start=0
16:48:24 <kmartin> woodspa:  Dietmar is on the dist. list
16:48:52 <jgriffith> I just wanted to remind folks to help keep an eye on things here
16:49:12 <jgriffith> We're in "ok" shape right now I think but I want to make sure we don't leave things sitting too long
16:49:32 <jgriffith> Remember anybody can jump in there and take on a bug if they like
16:49:32 <zykes-> oh
16:49:34 <woodspa> kmartin: not sure.  I just told him to contact you.
16:49:35 <zykes-> here we are ;p
16:49:45 <jgriffith> I'll try to make sure I keep on top of triage etc
16:49:50 <jgriffith> zykes-: You missed it :)
16:50:03 <jgriffith> zykes-: scroll up to see the conversation or check eavesdrop
16:50:12 <jgriffith> kmartin: is from HP and is driving some of the effort
16:50:41 <jgriffith> #topic reviews
16:50:52 <jgriffith> Again.. just a reminder as every week :)
16:50:57 <kmartin> woodspa: we have his contact info and he should of been notifed by Andre from Brocade, who is putting together this first meeting
16:51:15 <jgriffith> If you have 10 minutes a day to spare just go here: https://review.openstack.org/#/q/status:open+cinder,n,z
16:51:20 <jgriffith> and help out please :)
16:51:34 <woodspa> kmartin: perfect, thanks
16:51:45 <jgriffith> Especially my review: https://review.openstack.org/#/c/14266/
16:51:52 <jgriffith> ^^
16:51:52 <uvirtbot> jgriffith: Error: "^" is not a valid command.
16:51:58 <jgriffith> uvirtbot: whatevs
16:51:58 <uvirtbot> jgriffith: Error: "whatevs" is not a valid command.
16:52:04 <thingee> heh
16:52:13 <jgriffith> stupid uvirtbot
16:52:24 <jgriffith> Finally... I get the last word
16:52:26 <bswartz> uvirtbot: gdiaf
16:52:27 <uvirtbot> bswartz: Error: "gdiaf" is not a valid command.
16:52:56 <jgriffith> Ok... finally
16:53:02 <jgriffith> #topic core team status
16:53:26 <jgriffith> I don't see much reason to wipe out the core team and start over right now
16:53:41 <jgriffith> We could do some things like swap Rob and Ben
16:53:54 <bswartz> oh yes please
16:53:58 <jgriffith> Or if Ben mentioned somebody else will be working on Cinder we can just wait
16:53:58 <bswartz> I thought that was already done
16:54:16 <bswartz> no it should be me
16:54:16 <jgriffith> bswartz: No it wasn't :(
16:54:31 <jgriffith> Well... then you have to do core duty stuff :)
16:54:43 * jgriffith ropes bswartz into the muck
16:55:01 <bswartz> I fully intend to
16:55:14 <jgriffith> so just a reminder core means you're on IRC, you triage and fix bugs, do reviews etc etc
16:55:20 <jgriffith> bswartz: excellent
16:55:31 <jgriffith> If there are no objections then I move we swap Rob with Ben?
16:55:44 <jgriffith> Going once...
16:55:56 <jgriffith> Going twice...
16:56:02 <jgriffith> Done
16:56:09 <jgriffith> In addition....
16:56:28 <jgriffith> I'd like to formally propose a couple of new additions next week
16:56:49 <jgriffith> More to come on that, but if any of you have folks that you'd like to see nominated let me know
16:57:00 <jgriffith> I'll probably put something together for next week
16:57:55 <zykes-> Can I have e-mails for people in the cinder team if possible to work on FC stuff ?
16:58:10 <zykes-> I'm trying to pull in Dell folks as well on it
16:58:19 <jgriffith> zykes-: I'll leave that to kmartin.  A PM might be a more appropriate method
16:58:26 <zykes-> ok :)
16:58:28 <jgriffith> else we'll all spam kmartin to death!
16:58:30 <jgriffith> :)
16:58:51 <jgriffith> Oh wait... that's what openstack-dev.lists does already :)
16:59:07 <jgriffith> Ok... two minutes left
16:59:12 <jgriffith> #topic open-discussion
16:59:20 <jgriffith> anybody have anything?
16:59:40 <DuncanT> You threatened more on QoS if we had time?
16:59:44 <zykes-> jgriffith: are you gonna pull in people on the compute side as well or for the FC stuff ?
17:00:05 <jgriffith> zykes-: Not yet but the folks drafting it up are aware that will be required
17:00:16 <jgriffith> DuncanT: Yup, if nobody else has anything?
17:00:48 <zykes-> jgriffith: who can I bug to ask about stuff there
17:01:01 <jgriffith> zykes-: On nova?  Nobody yet :)
17:01:13 <jgriffith> zykes-: Not sure they've been made aware of the idea yet
17:01:15 <zykes-> aww ;p
17:01:16 <bswartz> #openstack-nova maybe?
17:01:31 <winston-d> or just ping vishy
17:01:52 <jgriffith> alright... qos?
17:01:52 <clayg> jgriffith: i'm here, catching up on the back log
17:01:59 <jgriffith> clayg: Howdy!
17:02:09 <clayg> yessir, been thinking alot about blueprints
17:02:16 <jgriffith> :)
17:02:25 <bswartz> Is "qos" really the best term to use? It's such a loaded acronym
17:02:34 <jgriffith> bswartz: ?
17:02:40 <jgriffith> quality of service ?
17:02:46 <jgriffith> seems pretty straight forward to me
17:03:07 <bswartz> I'm just saying that people think they know what QoS means -- and different people don't always agree
17:03:15 <jgriffith> bswartz: ahhh... fair
17:03:23 <DuncanT> Are we going to handle QoS specifically, or generic per-volume and per-volume-class attributes?
17:03:43 <jgriffith> DuncanT: That's the million dollar question I think :)
17:04:15 <jgriffith> DuncanT: My original intent was to actuall add a method to the API to make "special" settings to volumes
17:04:45 <DuncanT> I'd prefer the later, but the former is better from a self-documenting / explorable API
17:04:47 <jgriffith> DuncanT: ie "set_iops(min=x, max=y, burst=z)"
17:05:15 <jgriffith> but seemed like maybe that should be reserved to an extension
17:05:26 <jgriffith> then the other thing that came up was VT/ExtraSpecs
17:05:31 <clayg> +1 qos core on types, with per volume qos as ext
17:05:40 <DuncanT> I still don't understand extraspecs...
17:05:54 <jgriffith> DuncanT: so here's an example
17:05:57 <clayg> extraspecs is reserved metadata on types ya?
17:06:06 <jgriffith> clayg: yup
17:06:14 <jgriffith> volume_type=qos
17:06:59 <jgriffith> extra_specs={min:x, max:y, burst:z, blue:whatevs}
17:07:00 <jgriffith> The downside in that it's a set and forget
17:07:09 <jgriffith> It would be good to have an update handle
17:07:20 <DuncanT> So selecting a volume type tells you what per-volume metadata is valid at create?
17:07:31 <DuncanT> (were per-volume metadata == the extra specs field)?
17:07:32 <jgriffith> extra-specs aren't the same as volume_metadata
17:08:00 <DuncanT> Yeah, I'm overloadign the term metadata, sorry
17:08:01 <jgriffith> but yes, kinda.  It's arbitrary, the admin can assign whatever they want there
17:08:02 <DuncanT> Per-volume attributes
17:08:08 <jgriffith> DuncanT: +1
17:08:29 <winston-d> attributes/properties..
17:08:29 <jgriffith> So following what clayg pointed out (I think)
17:08:29 <bswartz> extra specs are additional information about the volume type that are available to the scheduler at scheduling time, and also available to the driver at create time
17:08:29 <clayg> capabilities <- sorry just needed to throw that out there :P
17:08:45 <jgriffith> You get the best of both worlds
17:09:09 <winston-d> bswartz, +1
17:09:16 <clayg> bswartz: that's a great definition
17:09:17 <jgriffith> You can provide the extension to explicitily change/set it as well
17:09:17 <DuncanT> To rephrase 'extra-specs are per-volume attributes/properties. The set of valid keys is decided on a per-volumetype basis'?
17:09:17 <jgriffith> bswartz: You da man!
17:09:23 <DuncanT> (Looking at this as a user, not an implementer)
17:09:40 <jgriffith> DuncanT: extra-specs wouldn't be visible to the user
17:09:45 <jgriffith> DuncanT: Only the admin
17:09:54 <DuncanT> Ah, ok
17:10:02 <jgriffith> Unless folks disagree with that?
17:10:09 <winston-d> jgriffith, no, it is visible to end-user, i think.
17:10:19 <clayg> jgriffith: I'm not sure that 100% nessecary, if some of the extraspec fields become common between backend impls they start to have meaning that may be relevant to an end user trying to select a type
17:10:25 <DuncanT> So basically they are just some stuff associated with a volumetpye by the admin?
17:10:25 <bswartz> no, only the volume_type is visible to the end user, not the extra specs
17:10:45 <clayg> it's not quite "RAM"  "CORES" - but things like min/max iops seem... sorta understood-ish?
17:10:53 <DuncanT> In that case I'm clear
17:11:12 <jgriffith> bswartz: You and are in alignment I think
17:11:14 <clayg> ok, i'm happy to be over-ruled on no extra specs are ever visable to the user ever
17:11:20 <jgriffith> But clayg
17:11:37 <jgriffith> I'm *ok* with it being visible, just not modifiable by the user
17:11:45 <jgriffith> It's immutable for a user
17:11:47 <clayg> jgriffith: oh yes obviously
17:11:49 <jgriffith> mutable for an admin
17:11:51 <winston-d> jgriffith, +1 for that
17:12:06 <clayg> jgriffith: totally clear, i don't really care if users can see them
17:12:09 <DuncanT> I'm not sure it makes sense to the user
17:12:14 <jgriffith> I point that out because I just thought my patch may be broken and not do that :(
17:12:21 <clayg> but I think about people going to GOLD type at provider a to FAST type at provider b
17:12:34 <bswartz> the danger with having it visible to the user is that the admin may want to modify the extra_specs for a volume type after some volumes have already been created, and such changes will not be retroactive
17:12:35 <winston-d> since volume_type is nothing but a name, expose extra_specs to end user can make things clear
17:12:37 <clayg> maybe not of it means anything until you benchmark
17:12:40 <jgriffith> Ok... I move to have it be admin visible only to start
17:12:52 <jgriffith> we can change it over the next couple of weeks if we think of good reason?
17:13:03 <clayg> yeah, makes good sense
17:13:09 <jgriffith> winston-d: But you may not want them to see that
17:13:10 <jdurgin> jgriffith: sounds good to me
17:13:12 <DuncanT> But the extra_specs is going to be full of back-end specific things
17:13:17 <jgriffith> winston-d: For example they select GOLD
17:13:29 <jgriffith> If they aren't using it, an admin can redefine what GOLD is :)
17:13:40 <jgriffith> sneaky optimization/efficiencey tricks
17:14:05 <jgriffith> Long explanation but there's some use cases that make having that hidden handy from an admins perspective
17:14:15 <jgriffith> DuncanT: correct
17:14:19 <DuncanT> My vote is leaning heavily to not showing it to non-admin
17:14:45 <jgriffith> DuncanT: +1
17:14:47 <DuncanT> Though one of the horizon guys suggested we might want to add a (free text) description field to each type
17:14:49 <woodspa> DuncanT: +1
17:14:50 <bswartz> there may also be value in have a "description" field for volume types that allows admins to write a fluffy description of what the volume type is -- that text could be displayed in horizon, for example.
17:15:02 <DuncanT> bswartz: +1 ;-)
17:16:03 <clayg> yeah, type description +1
17:16:07 <winston-d> my concern is volume_type is just a _name_, at RAX, GOLD means SSD backed volume, but maybe somewhere else, GOLD means something bad, that's confusing. there should be some way to avoid such confusion.
17:16:30 <bswartz> winston-d: how about the description field, would that address your issue?
17:17:02 <winston-d> type description is OK, i guess. at least it has potential to solve the problem i mentioned.
17:18:03 <bswartz> put it to a vote!
17:18:14 <clayg> I think some extra_specs just won't be reasonable to expose to end user, so if even if we say we want to expose them directly, we'd have to solve "hiding" some... it just gets message - description seems like the easiest thing, I retract all previous comments about having extra_specs exposed :P
17:18:30 <clayg> *exposed to user - types-manage ext has to expose them ;P
17:18:54 <clayg> s/message/messy
17:18:58 <clayg> wow
17:19:20 <jdurgin> I think a lot of extra_specs will end up being backend-dependent anyway, and even common ones won't necessarily be meaningful to a user's workload
17:19:22 * clayg thinks jgriffith is looking up how to do voting :D
17:19:27 <jgriffith> sorry
17:19:45 <jgriffith> phone call
17:19:45 <DuncanT> name & description only +1
17:19:55 <clayg> name & description only +1
17:19:55 <jgriffith> So I'm not going to put it to a vote
17:19:55 <woodspa> DuncanT +1
17:20:01 <jgriffith> I'm going to make an exec decision :)
17:20:09 <clayg> PTL'IN LIKE A BOSS
17:20:10 <winston-d> yeah, that makes sense. i'm fine with not exposing extra_specs to enduser, and +1 for description.
17:20:15 <jgriffith> :)
17:20:23 <jgriffith> it looks like everybody agrees anyway
17:20:31 * clayg snickers - *this time*
17:20:32 <jgriffith> extra_specs not exposed to end udser
17:20:44 <rongze> name & description only +1
17:20:56 <jgriffith> clayg: if they didn't I'd do a vote... I'd just rig the results :)
17:21:03 <jgriffith> Alright, let's go with that
17:21:15 <jgriffith> if something scary comes up we can revisit :)
17:21:18 <jgriffith> So....
17:21:28 <jgriffith> I think we go with clayg s recommendation
17:21:39 <jgriffith> type/extra-spec for quality settings
17:21:40 <clayg> whay, wut?  I have only _bad_ ideas
17:21:51 <jgriffith> and also provide an extension for direct access by and admin
17:21:57 <jgriffith> clayg: :)
17:22:00 <DuncanT> So are we punting per-volume settings for now?
17:22:06 <clayg> i don't think that was my idea, but it sounds good
17:22:10 <kmartin> is there a blue print for the volume type and extra specs?
17:22:10 <jgriffith> clayg: I think that's what you said?
17:22:13 <jgriffith> Doh
17:22:33 <winston-d> kmartin, volume type & extra specs are already there.
17:22:36 <jgriffith> kmartin: Nope, it's something that's always been there
17:22:37 <clayg> yeah, i said that, but I thought I was rephrasing you :D
17:22:41 <jgriffith> kmartin: just never used
17:22:45 <winston-d> kmartin, just hasn't been utilized yet.
17:22:59 <kmartin> ok that's what I thought
17:23:04 * jgriffith twists clayg 's statements around to his advantage
17:23:35 <jgriffith> How about I write it up and post it and you guys can all puke on it if you like :)
17:23:49 <jgriffith> I'll put a wiki together before the next meeting?
17:24:03 <DuncanT> Sounds like a plan
17:24:06 <jgriffith> cool
17:24:18 <jgriffith> Alright, we're way over... and that silly sales guy is going to call me back
17:24:27 <jgriffith> so I better get some coffeee beforehand :)
17:24:41 <jgriffith> As always you can catch me on IRC any time
17:24:49 <jgriffith> And THANKS!!!
17:25:05 <jgriffith> I thought the summit went really well and think we've made great progress with Cinder!
17:25:31 <jgriffith> Ok... anything real quick before I cut this off!
17:25:40 <jgriffith> #endmeeting cinder