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