16:01:03 <jgriffith> #startmeeting cinder
16:01:04 <openstack> Meeting started Wed Aug 22 16:01:03 2012 UTC.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:06 <openstack> The meeting name has been set to 'cinder'
16:01:15 <jgriffith> hey everyone!
16:01:18 <thingee_zz> o/
16:01:23 <rturk_> hello
16:01:32 <bswartz> hi
16:02:03 <winston-d> hi
16:02:07 <DuncanT> hey
16:02:11 <cian_> hi
16:02:15 <jgriffith> Ok...  looks like we have a number of folks, let's get started :)
16:02:24 <jgriffith> #topic cidner-usecases
16:02:34 <jgriffith> http://etherpad.openstack.org/cinder-usecases
16:02:54 <jgriffith> I had a conversation with winston-d last night on this and think we came up with something we agree on
16:03:12 <jgriffith> volume_type should be used for scheduling to different cinder/volume nodes
16:03:46 <jgriffith> This may be differentiated by network speed (10G versu 1G)
16:03:57 <DuncanT> All of our volume nodes are equivilent, same as ceph...
16:03:57 <jgriffith> or any other parameter the provider chooses
16:04:13 <jgriffith> DuncanT: So that's fine, that just means this doesn't do anything for you
16:04:16 <jgriffith> :)
16:04:43 <bswartz> wait
16:04:50 <DuncanT> Does that mean we can't use volume types? Seems rather limiting
16:04:50 <jgriffith> bswartz: go
16:04:59 <bswartz> do you mean used to choose between different backends?
16:05:05 <jgriffith> DuncanT: No, it does not mean that
16:05:22 <jgriffith> bswartz: That can be achieved via volume_types yes
16:05:29 <bswartz> ceph could just represent one backend amoung others
16:05:32 <DuncanT> Sorry, I'm misunderstanding you then
16:05:55 <bswartz> so volume_type would allow the schedule to choose a ceph backend vs a different backend, right?
16:06:03 <bswartz> scheduler*
16:06:11 <winston-d> sure
16:06:12 <jgriffith> bswart: yes via the volume node
16:06:29 <jgriffith> bswartz: Since we still have the limit of one backend per node it works nicely that way
16:06:49 <bswartz> and the individual driver can make additional decisions based on volume_type after the scheduler has selected that particular driver?
16:07:10 <jgriffith> bswartz: So it would use the volume_type extra_specs... yes
16:07:27 <jgriffith> Which I believe is something DuncanT and some others suggested before
16:07:37 <jgriffith> But I was stubborn :)
16:07:42 <bswartz> I thought volume_type_extra_specs were system-wide and staticly defined by the user
16:08:02 <bswartz> user = OpenStack admin
16:08:16 <winston-d> yes, the information in volume_type can be used to determine which nodes are capable of creating such volume, and also volume_type might contain information for driver to do customize volume it creates
16:08:53 <DuncanT> winston-d: The second part of that statement is what I wanted to hear, thanks. Consider me in agreement
16:09:10 <winston-d> DuncanT, :)
16:09:44 <jgriffith> bswartz: feel better, or still concerns?
16:10:17 <bswartz> I'm okay with the decision, I'm unclear on how volume_type_extra_specs solves any problems
16:10:33 <jgriffith> bswartz: That's becuase right now it really doesn't :)
16:11:32 <jgriffith> bswartz: We just need to clarify what the intent was when these were created
16:11:51 <winston-d> bswartz, mind elaborate a bit more on the problem/concern you have?
16:11:52 <jgriffith> bswartz: We also need to agree upon what volume type scheduling is and move forward with it
16:13:00 <jgriffith> bswartz: anything?
16:13:11 <bswartz> winston-d: when we wrote the NetApp driver, we needed a way to allow users to specify different service levels
16:13:25 <bswartz> winston-d: and we looked at the options and chose volume_type
16:13:47 <bswartz> winston-d: we also looked at volume_type_extra_specs and decided that feature was useless for our purposes
16:14:18 <winston-d> well, from end user perspective, it works the other way around.
16:14:57 <winston-d> user choose to create a volume with certain 'volume_type', expecting to get corresponding service.
16:15:30 <bswartz> so, in the NetApp driver, the set of supported volume_types is defined externally
16:16:08 <jgriffith> bswartz: But the problem is they're all still volume type *netapp* no?
16:16:35 <bswartz> jgriffith: no
16:16:48 <winston-d> yes, idea is very similar to 'instance_type' or 'flavor' in Nova, if you have some background on that.
16:16:58 <bswartz> we support the concept of "gold", "silver", etc volume types
16:17:13 <jgriffith> bswartz: Different driver and backend device for each?
16:17:15 <winston-d> maybe if we change the name 'volume_type' to 'volume_flavor', things can be easier to understand?
16:17:30 <bswartz> but policies that define the differences between the services levels exists in NetApp management software
16:17:49 <bswartz> the openstack driver merely sends the request for gold/silver/etc storage
16:18:05 <jgriffith> bswartz: You mean the netapp driver
16:18:10 <bswartz> yeah
16:18:20 <bswartz> so the current arrangement works fine for us
16:18:25 <jgriffith> bswartz: I understand what you're saying as I have the same challenge
16:18:36 <bswartz> but volume_type_extra_specs doesn't add anything useful for our driver
16:18:37 <jgriffith> bswartz: Also, I'm not asking you to change it for Folsom
16:18:52 <jgriffith> For Grizzly I would like to hammer out a more elegant solution for things like driver specific details
16:19:07 <jgriffith> err... back-end driver specific details
16:19:19 <bswartz> actually -- I can think of one thing
16:19:52 <bswartz> we could use volume_type_extra_specs to create a mapping from volume_type names understood by openstack to service levels understood by netapp software
16:20:09 <winston-d> bswartz, exactly!
16:20:33 <jgriffith> bswartz: That's the whole idea
16:20:36 <winston-d> that's how i want to implement that.
16:20:39 <bswartz> okay
16:20:46 <bswartz> currently the strings just have to match
16:20:48 <jgriffith> bswartz: It's just that nobody (including myself) have done it yet
16:21:14 <bswartz> but a mapping table allows the user to use different strings, so that has some value
16:21:19 <winston-d> scheduler will pick your backend, only because your backend driver states that it supports feature in 'extra_spec'.
16:21:43 <bswartz> winston-d: I would like to see a concrete example of that
16:22:02 <jgriffith> Ok, are we all happy with moving forward on this at this point?
16:22:03 <DuncanT> Shall we write one up on etherpad?
16:22:28 <jgriffith> DuncanT: I think it would be good to have a summary/decision section yes
16:22:44 <bswartz> I'd specifically like to see a howto type document for running 2 different drivers in the same environment, including how to make the scheduler to the right thing
16:23:15 <DuncanT> Ok, let's try getting that added to the etherpad after the meeting?
16:23:15 <vincent_hou> that would be amazing.
16:23:35 <DuncanT> The scheduler ahsn't been written yet is the biggest issue I think :-)
16:23:42 <bswartz> uh oh
16:24:11 <bswartz> so I'm guessing there won't be a scheduler for cinder in folsom then?
16:24:34 <winston-d> for example, we have a very basic volume_type called 'standard_volume', it has one extra_spec, that's '4k_IOPS_capability':1,000.
16:24:48 <winston-d> bswartz, well, we have a very simple one.
16:24:54 <DuncanT> Well, if you consider the fact there isn't one a bug rather than a missing feature, we /could/ add one next week...
16:25:04 <jgriffith> DuncanT: It's a bug!
16:25:10 <DuncanT> :-)
16:25:21 <jgriffith> So just fyi this is what's been driving the conversation
16:25:49 <jgriffith> winston-d: had started ideas on a volume type scheduler but the disagreements on volume_types meant we needed to clear that up first
16:26:16 <winston-d> jgriffith, i agree
16:26:41 <DuncanT> Shall we aim to have examples up on etherpad in the next 24 hours, then if nobody loudly disagrees with them somebody can make a start ont he code?
16:26:45 <winston-d> truth is, currently the 'volume_type' table in DB has only one column 'name'...
16:27:03 <jgriffith> winston-d: I can fix the DB easily enough
16:27:11 <winston-d> DuncanT, agree.
16:27:15 <DuncanT> I think concrete examples of setups are the most useful thing at this point
16:27:21 <jgriffith> winston-d: Once we decide what we want I can turn that around quickly
16:27:48 <jgriffith> DuncanT: winston-d: I agree, post it, but I also think our discussion here as core team gives us enough to get started
16:28:05 <jgriffith> DuncanT: +1 for concrete examples
16:28:39 <jgriffith> Ok, if there's no lingering questions shall we move on to the next topic?
16:28:41 <winston-d> so, let's talk about what 'volume_type' should be/contain?
16:28:48 <jgriffith> Or would you all like to spend some more time on the details here?
16:29:15 <bswartz> do we have the time available?
16:29:39 <jgriffith> bswartz: So this is probably important enough to spend the meeting time on
16:29:55 <jgriffith> we can defer the other discussions, or folks can meet up in #openstack-cidner
16:29:58 <jgriffith> cinder
16:30:05 <DuncanT> I think a volume type should just be a mapping between a name and a list of conditions that the scheduler and driver can both consume
16:30:49 <bswartz> can there be multiple scheduler implementations or just 1?
16:30:55 <DuncanT> Multiple
16:31:10 <DuncanT> Though it might be possible to have one handle most usecases...
16:31:45 <bswartz> assuming there is a "default" scheduler designed to address most users needs, who decides which "conditions" it understands?
16:31:51 <winston-d> DuncanT, agree. and also volume type should be easy enough for end user to use, for now i think that's the only interface end user has to define what he/she needs (beside capacity).
16:32:08 <jgriffith> bswartz: default scheduler is a *simple* scheduler that does nothing more than a round-robin type assignment
16:32:34 <bswartz> jgriffith: is that likely to satisfy a majority of users?
16:32:43 <jgriffith> depends....
16:32:45 <DuncanT> The better scheduler can be made to unserstand '=', '>', '<', '!='... what else do you want?
16:32:59 <DuncanT> s/unserstand/understand/
16:33:01 <jgriffith> If they have multiple back-ends, then not likely
16:33:20 <winston-d> bswartz, no, not at all. i plan to implement a filter scheduler, which can consume custom filter to do more advanced scheduling.
16:33:49 <jgriffith> bswartz: You can get a feel for some of this by looking at the compute schedulers in Nova
16:34:00 <jgriffith> bswartz: It's going to be the same design
16:34:14 <DuncanT> So your volume_type 'super fast premium' might map to 'type == hp-block, min_iops > 1000000, existing_volumes<100'
16:34:27 <bswartz> so what is the integration point between the scheduler and the driver?
16:34:43 <bswartz> is it this 'type' field in the volume_type_extra_specs?
16:35:34 <jgriffith> bswartz: Depending on what you mean there is *no* real integration point
16:36:03 <jgriffith> bswartz: scheduler selects which volume node to use
16:36:18 <jgriffith> The rest is abstracted out
16:36:26 <winston-d> 'super fast premium' is just a name tag, right? what makes things work is the definition/properties under such name, 'type == hp-block, min_iops > 100,000' are the real useful information from scheduler stand point
16:36:27 <jgriffith> So let's try and focus on one conversation at a time here
16:36:27 <bswartz> how does scheduler know that one driver (or node) has different capabilities than another?
16:37:03 <jgriffith> bswartz: combination of the volume_type and extra_specs info
16:37:13 <winston-d> bswartz, this requires each driver to report the capabilities to DB.
16:37:25 <bswartz> aha
16:37:26 <DuncanT> bswartz: There is a call to the driver for it to report capabilities
16:37:38 <bswartz> so drivers do need to report their capabilities
16:37:39 <winston-d> we have it now, 'report_driver_status' method
16:37:44 <bswartz> I would call that an integration point