17:05:40 <renuka> #startmeeting
17:05:42 <openstack> Meeting started Thu Nov  3 17:05:40 2011 UTC.  The chair is renuka. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:05:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:05:54 <renuka> #topic Volume Affinity
17:06:20 <renuka> It might be useful to have your thoughts online, so anyone else can read it later
17:06:21 <DuncanT> http://wiki.openstack.org/VolumeAffinity has the details I've put up so far
17:06:36 <renuka> #link http://wiki.openstack.org/VolumeAffinity
17:07:06 <renuka> So what do you expect will go as key value pairs?
17:08:09 <renuka> Have you decided how you will extend the volume create API?
17:08:22 <DuncanT> Yes, it looked like "affinity:volume1,volume2,volume3 anti-affinity:volume4" notation could express what we are thinking of
17:08:33 <DuncanT> No, the API was an open issue
17:08:59 <DuncanT> volume-types doesn't allow key-value pairs at create time as it stands
17:09:31 <renuka> vishy: Should API related things be taken up in the nova api meeting or should we come up with extensions here
17:09:41 <vishy> extensions here
17:09:54 <DuncanT> Vladimir and I couldn't see a reason not to add an 'extras' field, that can contain key-value pairs, with only affinity and anti-affinity being defined for now
17:09:58 <vishy> volume api will be separated out so you guys will be responsible for it
17:10:23 <vishy> ultimately affinity to computes would be interesting as well
17:10:24 <renuka> vishy: right, thanks
17:10:30 <vishy> but that seems like a good start
17:10:57 <renuka> vishy: I agree. That will likely help boot from volume
17:10:58 <DuncanT> Should we call it 'volume-affinity' and volume-anti-affinity' to avoid ambiguities later then?
17:11:19 <vishy> sure
17:11:42 <vishy> or perhaps it could be affinity:volume-<id>
17:11:46 <renuka> Do you think we should have something as generic as extras in the API?
17:11:56 <vishy> and we could use instance-<id> for computes
17:11:58 <renuka> If this has structure, why not make it an actual option?
17:12:19 <renuka> vishy: +!
17:12:31 <renuka> I meant +1 :P
17:12:34 <vishy> leaving room for other types in the future without having an explosion of keys
17:12:42 <DuncanT> I'm thinking we're likely to want to add other options in future
17:13:37 <renuka> I don't understand. (Potential noob question). If someone has to use the option, they would have to know the key affinity
17:13:57 <renuka> So anyone using specific things in extras needs to know the keywords
17:14:21 <renuka> By adding extras, we have to add the parsing for it.. doesn't that get more complicated later?
17:15:49 <vishy> true
17:16:04 <DuncanT> key:value pairs end up being a json dictionary, which has a standard parsing
17:16:10 <renuka> Plus the API is not self explanatory.. because there could be all sorts of features that go in as "extras"
17:16:31 <vishy> this is the general idea behind api extensions
17:16:46 <vishy> extensions can be added to support specific features
17:17:42 <renuka> vishy: but that is exactly why I would think we need not have another layer of generic options... unless we think we need them. Like in the case of connectivity, there is no way we can support all the options that all storage types have
17:17:46 <vishy> key value do seem like undocumented features
17:18:28 <vishy> internally they make sense
17:18:48 <vishy> but i think what is exposed to the api should attempt to be actual options in the request
17:18:49 <renuka> but in case of affinity/anti-affinity, we seem to have the keywords nailed. Anything else like compute that gets added later, can go in, as you said affinity: volume-id, compute-id, etc
17:18:51 <DuncanT> I'm not wedded to the idea, it just seems cleaner than having to make structural changes to clients to support some minor API feature
17:18:58 <vishy> so that they can be documented.
17:19:19 <vishy> if it is an optional parameter
17:19:25 <vishy> clients can ignore it
17:19:41 <vishy> i guess i see where you are going though
17:20:24 <vishy> if a vendor wants to add a new parameter, they would have to go and modify the client to know about it
17:20:43 <DuncanT> vish: Quite
17:20:54 <vishy> that seems like something that is useful to bring up in the nova-api meeting
17:20:59 <renuka> Why in this case, in particular?
17:21:11 <vishy> scheduler hints
17:21:18 <renuka> wouldn't affinity and anti-affinity keywords be sufficient?
17:21:35 <vishy> renuka: in this case, but what if there are other scheduler hints
17:21:52 <vishy> ssd:preferred
17:21:57 <vishy> or something along those lines
17:22:24 <renuka> vishy: I thought we agreed that types should be used for that
17:22:26 <vishy> every new hint would have to be added to the client
17:22:40 <vishy> renuka: types are great for requirements but not hints
17:23:01 <vishy> optimize:latency vs optimize:bandwidth
17:23:19 <renuka> makes sense
17:23:26 <DuncanT> If we rename 'extras' as 'hints' and define it as information the volume driver/scheduler is free to ignore, does that help?
17:23:47 <renuka> right, so I like the renaming. Just to ensure that we don't end up adding other functionality there, just because we can
17:23:58 <vishy> in any case, i think we should discuss it in the api meeting.  What should be codified into a documented option, and what is ok to stick in as key value pairs
17:24:27 <vishy> my rough pass would be ignorable data (like hints) are ok as key/value pairs
17:24:49 <DuncanT> vish: That makes good sense
17:25:02 <vishy> #action vishy to bring up key-value pairs vs extensions in the nova-api meeting
17:25:18 <vishy> #action vishy to bring up separate-volume-api in the nova-api meeting
17:25:57 <vishy> i have to go grab some lunch before it is gone, can I throw in a request before i go?
17:26:04 <renuka> sure
17:26:23 <vishy> I would really like you guys to start reviewing all volume related patches that are thrown into gerrit
17:26:27 <vishy> for example: https://review.openstack.org/#change,1202
17:26:55 <vishy> even if it is just to say, that looks fine
17:27:11 <renuka> will do
17:27:16 <tim-at-home> ok willn do
17:27:20 <DuncanT> vish: I've been playing with that code today funny enough
17:27:21 <tim-at-home> will
17:27:46 <vishy> #action volume team to start reviewing volume related code in gerrit
17:27:49 <vishy> great
17:28:32 <dricco> yup will do
17:29:25 <renuka> Right, so anything else to be discussed for affinity? This blueprint will be implemented by HP, correct?
17:30:27 <DuncanT> renuka: Yes, though it is closely tied to the volume-types work in places
17:31:48 <renuka> DuncanT: right, so the volume-types work is already in, correct?
17:33:15 <DuncanT> renuka: I'm not certain it is in its final form, but I'll check with Vladimir and make sure we don't cause each other headaches
17:34:00 <renuka> #action HP to look into volume types requirements and implement Volume Affinity/Anti Affinity
17:34:39 <renuka> The next thing i wanted to bring up was the need for an admin API for dynamic storage
17:34:53 <renuka> Does anyone else feel the need for this?
17:35:25 <tim-at-home> renuka, what do you mean by dynamic storage?
17:36:02 <renuka> tim-at-home: We do not use storage local to the nova-volume node for volumes
17:36:30 <renuka> so we end up having to "add" our storage backends/arrays and remove them when they need to be offline etc
17:36:38 <tim-at-home> renuka, gotcha -
17:36:48 <DuncanT> renuka: Is this something that will end up generic, or is it better as a vendor extension?
17:36:58 <tim-at-home> wont this be very specific?
17:37:05 <renuka> At the moment, the xen storage manager driver has its own table, and uses the nova-manage command to add/remove this
17:37:44 <renuka> this is how the nova-manage command looks at the moment:
17:37:46 <renuka> nova-manage sm backend_add <flavor label> <SR type> [config connection parameters]
17:38:06 <renuka> flavor here means type (needs to be refactored)
17:38:13 <tim-at-home> for example we have a proprietary API for managing our storage - it is very specific to our particular  archtiectrure
17:38:55 <renuka> So I guess we are leaning towards vendor extensions then
17:39:31 <tim-at-home> I do not feel strongly about it,
17:39:37 <tim-at-home> ohters?
17:39:38 <DuncanT> I think so. We might look at how much commonality there is later, but I don't see any advantage at the moment
17:39:57 <rnirmal> each vendor already has existing tools to manage this, should we recreate them within the context of nova
17:41:39 <renuka> without a common table that contains the storage available in the zone, would be still be able to function well across various vendors/storage types?
17:42:27 <DuncanT> Surely the available storage is know dynamically by the scheduler based on what nova-volume servers present themselves?
17:43:08 <renuka> right, i guess report capabilities can be used appropriately
17:43:26 <tim-at-home> agree
17:44:48 <renuka> next up was the netapp blueprint that robert mentioned on the emails. Is anyone from netapp here?
17:45:32 <renuka> guess not
17:45:47 <renuka> Anything else anyone would like to bring up?
17:46:23 <DuncanT> Is boot-from-volume going to be discussed at some point?
17:46:38 <renuka> We are certainly interested in that
17:46:49 <tim-at-home> is anyone using it?
17:46:52 <DuncanT> The current situation, aims and functionality is not very clear, and the current shape of the API is very limiting
17:47:10 <renuka> I agree
17:47:22 <tim-at-home> me 2
17:47:29 <renuka> The code seems to be there for libvirt, but I haven't used it
17:48:13 <tim-at-home> should we ask Morita-san to come along?
17:49:48 <renuka> should we bring this up on an email thread for visibility?
17:50:21 <tim-at-home> I think that is a good idea. I certainly find it difficult to understand exactly what is there
17:50:27 <DuncanT> It would definitely be worth getting all of the interested parties involved, yes
17:50:44 <renuka> DuncanT: Is there anything in particular you would like to see in the API for example?
17:51:29 <DuncanT> renuka: I'd like to see an API for generically plugging volumes onto an instance/server  before it is booted, and setting the boot device
17:51:51 <DuncanT> Rather than limiting it to the ec2 boot-onto-a-cloned-copy only
17:52:20 <renuka> DuncanT: there is a BootFromVolumeController in the openstack api
17:52:26 <renuka> extensions
17:52:45 <DuncanT> renuka: I saw it, it is not clear how it is supposed to work
17:53:24 <renuka> #action bring up boot from volume on email thread to get an idea of current state/goals
17:53:46 <DuncanT> For example, if I have vm1 create & prepare (fill) a volume, then detach I'd like to be able to provision a new vm that boots from that volume
17:53:54 <DuncanT> (or volumes)
17:55:02 <jdurgin> DuncanT: this exists as an OS api extension, but it could use some cleaning up
17:55:17 <tim-at-home> I think it would be good to consolidate the boot from volume *& the recent autocreatebootvoluems into a logical set of volume & boot capabilities
17:55:39 <renuka> agreed
17:57:12 <renuka> Right, we have about 3 minutes remaining. Anything else that needs to be brought up in the future?
17:57:34 <tim-at-home> i'm good
17:57:36 <DuncanT> I can't think of anything at the moment
17:57:45 <dricco> good here too
17:58:05 <renuka> so I noticed we have the nova volume meeting set to happen every Thursday
17:58:19 <renuka> just wanted to confirm that everyone feels the need for a weekly meeting
17:58:41 <DuncanT> There have been things to discuss every week so far
17:59:04 <tim-at-home> I think at present it is a good timing,. As it happens I will be AWOL next week
17:59:21 <renuka> ok. let us keep it that way
17:59:47 <renuka> alright, thanks everyone.
17:59:51 <tim-at-home> ciao
18:00:02 <renuka> #endmeeting