Thursday, 2011-11-03

*** andreaf has quit IRC00:00
*** cdub has quit IRC00:00
*** nati2 has quit IRC00:21
*** vladimir3p has joined #openstack-meeting00:22
*** cdub has joined #openstack-meeting00:27
*** adjohn has quit IRC00:29
*** jakedahn has quit IRC00:29
*** jakedahn has joined #openstack-meeting00:29
*** adjohn has joined #openstack-meeting00:29
*** novas0x2a|laptop has quit IRC00:31
*** nati2 has joined #openstack-meeting00:36
*** dragondm has quit IRC00:48
*** cdub has quit IRC00:49
*** jakedahn has quit IRC00:56
*** adjohn has quit IRC01:01
*** danwent has quit IRC01:17
*** cdub has joined #openstack-meeting01:21
*** jog0 has joined #openstack-meeting01:24
*** ron-slc has quit IRC01:28
*** jog0 has quit IRC01:31
*** jakedahn has joined #openstack-meeting01:39
*** cdub has quit IRC01:47
*** jog0 has joined #openstack-meeting01:48
*** jog0 has quit IRC02:07
*** shang has joined #openstack-meeting02:10
*** danwent has joined #openstack-meeting02:26
*** mmetheny has joined #openstack-meeting03:15
*** dendrobates is now known as dendro-afk03:17
*** novas0x2a|laptop has joined #openstack-meeting03:18
*** dendro-afk is now known as dendrobates03:18
*** sleepsontheflo-1 has joined #openstack-meeting03:41
*** adjohn has joined #openstack-meeting03:46
*** nati2_ has joined #openstack-meeting04:00
*** nati2 has quit IRC04:02
*** dendrobates is now known as dendro-afk04:08
*** vladimir3p has quit IRC04:08
*** dendro-afk is now known as dendrobates04:08
*** nati2_ has quit IRC04:11
*** nati2 has joined #openstack-meeting04:12
*** nati2 has quit IRC04:16
*** jog0 has joined #openstack-meeting04:19
*** jog0 has quit IRC04:29
*** gyee has quit IRC04:44
*** vladimir3p has joined #openstack-meeting05:15
*** vladimir3p has quit IRC05:31
*** donaldngo_hp has quit IRC05:32
*** adjohn has quit IRC05:40
*** cdub has joined #openstack-meeting06:10
*** novas0x2a|laptop has quit IRC06:11
*** jog0 has joined #openstack-meeting06:13
*** jog0 has quit IRC06:15
*** andreaf has joined #openstack-meeting06:59
*** andreaf has quit IRC07:38
*** jdag has quit IRC08:10
*** jdag has joined #openstack-meeting08:11
*** jdag has quit IRC08:17
*** dendrobates is now known as dendro-afk09:10
*** dendro-afk is now known as dendrobates09:29
*** darraghb has joined #openstack-meeting09:31
*** adjohn has joined #openstack-meeting09:40
*** adjohn has quit IRC09:40
*** dolphm has joined #openstack-meeting10:47
*** dolphm has quit IRC10:51
*** dolphm has joined #openstack-meeting11:17
*** dolphm has quit IRC11:47
*** dolphm has joined #openstack-meeting12:22
*** hggdh has joined #openstack-meeting12:28
*** cdub_ has joined #openstack-meeting12:29
*** cdub has quit IRC12:29
*** dolphm has quit IRC12:45
*** hggdh has quit IRC12:47
*** dprince has joined #openstack-meeting12:47
*** dolphm has joined #openstack-meeting13:00
*** hggdh has joined #openstack-meeting13:03
*** mmetheny has quit IRC13:28
*** mmetheny_ has joined #openstack-meeting13:28
*** dolphm has quit IRC13:32
*** hggdh has quit IRC13:37
*** dolphm has joined #openstack-meeting13:39
*** dolphm has quit IRC13:46
*** dolphm has joined #openstack-meeting13:48
*** joesavak has joined #openstack-meeting14:16
*** jsavak has joined #openstack-meeting14:22
*** joesavak has quit IRC14:26
*** mattray has joined #openstack-meeting14:28
*** danwent has quit IRC14:38
*** rnirmal has joined #openstack-meeting14:41
*** dendrobates is now known as dendro-afk14:50
*** adjohn has joined #openstack-meeting15:00
*** hggdh has joined #openstack-meeting15:04
*** dragondm has joined #openstack-meeting15:05
*** Gordonz has joined #openstack-meeting15:06
*** jdg has joined #openstack-meeting15:19
*** Gordonz has quit IRC15:25
*** Gordonz has joined #openstack-meeting15:25
*** adjohn has quit IRC15:27
*** dolphm has quit IRC15:27
*** hggdh has quit IRC15:29
*** dolphm has joined #openstack-meeting15:30
*** cdub_ has quit IRC15:33
*** dendro-afk is now known as dendrobates15:55
*** dendrobates is now known as dendro-afk15:59
*** reed has joined #openstack-meeting16:09
*** jog0 has joined #openstack-meeting16:13
*** rohitk has joined #openstack-meeting16:35
*** jog0 has quit IRC16:43
*** jog0 has joined #openstack-meeting16:43
*** renuka has joined #openstack-meeting16:53
*** jdurgin has joined #openstack-meeting16:57
*** dricco has joined #openstack-meeting17:00
renukaHello, shall we start the openstack volumes meeting?17:00
*** jog0 has left #openstack-meeting17:00
vishyis anyone else here?17:01
renukaI was trying to find out... I didn't get many responses for the email17:01
DuncanTI'm here (Duncan from HP)17:01
driccoI'm here (Cian from HP)17:01
*** jdg_ has joined #openstack-meeting17:02
renukaDuncanT: have you had the chance to hash out the design of volume affinity?17:02
renukaif you think that you have something to discuss on that front, we could have the meeting now17:03
DuncanTI put up a blueprint... the brief discussion I had with Vladimir last week seemed to suggest that it causes him no problems and basically just appears as a key-value pair at volume create time17:04
DuncanTI'm happy to discuss anybody else's thoughts on it17:05
*** reed has quit IRC17:05
vishyif there isn't a meeting17:05
openstackMeeting started Thu Nov  3 17:05:40 2011 UTC.  The chair is renuka. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.17:05
renuka#topic Volume Affinity17:05
*** openstack changes topic to "Volume Affinity"17:05
renukaIt might be useful to have your thoughts online, so anyone else can read it later17:06
DuncanT has the details I've put up so far17:06
renukaSo what do you expect will go as key value pairs?17:07
renukaHave you decided how you will extend the volume create API?17:08
DuncanTYes, it looked like "affinity:volume1,volume2,volume3 anti-affinity:volume4" notation could express what we are thinking of17:08
DuncanTNo, the API was an open issue17:08
DuncanTvolume-types doesn't allow key-value pairs at create time as it stands17:08
renukavishy: Should API related things be taken up in the nova api meeting or should we come up with extensions here17:09
vishyextensions here17:09
DuncanTVladimir 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 now17:09
vishyvolume api will be separated out so you guys will be responsible for it17:09
*** tim-at-home has joined #openstack-meeting17:09
vishyultimately affinity to computes would be interesting as well17:10
renukavishy: right, thanks17:10
vishybut that seems like a good start17:10
renukavishy: I agree. That will likely help boot from volume17:10
DuncanTShould we call it 'volume-affinity' and volume-anti-affinity' to avoid ambiguities later then?17:10
vishyor perhaps it could be affinity:volume-<id>17:11
renuka Do you think we should have something as generic as extras in the API?17:11
vishyand we could use instance-<id> for computes17:11
renukaIf this has structure, why not make it an actual option?17:11
renukavishy: +!17:12
renukaI meant +1 :P17:12
vishyleaving room for other types in the future without having an explosion of keys17:12
*** rohitk has quit IRC17:12
DuncanTI'm thinking we're likely to want to add other options in future17:12
renukaI don't understand. (Potential noob question). If someone has to use the option, they would have to know the key affinity17:13
renukaSo anyone using specific things in extras needs to know the keywords17:13
renukaBy adding extras, we have to add the parsing for it.. doesn't that get more complicated later?17:14
DuncanTkey:value pairs end up being a json dictionary, which has a standard parsing17:16
renukaPlus the API is not self explanatory.. because there could be all sorts of features that go in as "extras"17:16
*** dolphm has quit IRC17:16
vishythis is the general idea behind api extensions17:16
vishyextensions can be added to support specific features17:16
renukavishy: 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 have17:17
vishykey value do seem like undocumented features17:17
vishyinternally they make sense17:18
vishybut i think what is exposed to the api should attempt to be actual options in the request17:18
renukabut 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, etc17:18
DuncanTI'm not wedded to the idea, it just seems cleaner than having to make structural changes to clients to support some minor API feature17:18
vishyso that they can be documented.17:18
*** gyee has joined #openstack-meeting17:19
vishyif it is an optional parameter17:19
vishyclients can ignore it17:19
vishyi guess i see where you are going though17:19
*** jdurgin has quit IRC17:19
vishyif a vendor wants to add a new parameter, they would have to go and modify the client to know about it17:20
*** Gordonz has quit IRC17:20
DuncanTvish: Quite17:20
vishythat seems like something that is useful to bring up in the nova-api meeting17:20
renukaWhy in this case, in particular?17:20
vishyscheduler hints17:21
renukawouldn't affinity and anti-affinity keywords be sufficient?17:21
*** rohitk has joined #openstack-meeting17:21
vishyrenuka: in this case, but what if there are other scheduler hints17:21
*** gyee has quit IRC17:21
vishyor something along those lines17:21
renukavishy: I thought we agreed that types should be used for that17:22
vishyevery new hint would have to be added to the client17:22
vishyrenuka: types are great for requirements but not hints17:22
vishyoptimize:latency vs optimize:bandwidth17:23
renukamakes sense17:23
DuncanTIf we rename 'extras' as 'hints' and define it as information the volume driver/scheduler is free to ignore, does that help?17:23
renukaright, so I like the renaming. Just to ensure that we don't end up adding other functionality there, just because we can17:23
vishyin 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 pairs17:23
vishymy rough pass would be ignorable data (like hints) are ok as key/value pairs17:24
DuncanTvish: That makes good sense17:24
vishy#action vishy to bring up key-value pairs vs extensions in the nova-api meeting17:25
vishy#action vishy to bring up separate-volume-api in the nova-api meeting17:25
vishyi have to go grab some lunch before it is gone, can I throw in a request before i go?17:25
vishyI would really like you guys to start reviewing all volume related patches that are thrown into gerrit17:26
vishyfor example:,120217:26
vishyeven if it is just to say, that looks fine17:26
renukawill do17:27
tim-at-homeok willn do17:27
DuncanTvish: I've been playing with that code today funny enough17:27
vishy#action volume team to start reviewing volume related code in gerrit17:27
driccoyup will do17:28
renukaRight, so anything else to be discussed for affinity? This blueprint will be implemented by HP, correct?17:29
*** novas0x2a|laptop has joined #openstack-meeting17:29
DuncanTrenuka: Yes, though it is closely tied to the volume-types work in places17:30
renukaDuncanT: right, so the volume-types work is already in, correct?17:31
*** joesavak has joined #openstack-meeting17:32
DuncanTrenuka: 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 headaches17:33
renuka#action HP to look into volume types requirements and implement Volume Affinity/Anti Affinity17:34
renukaThe next thing i wanted to bring up was the need for an admin API for dynamic storage17:34
*** Gordonz has joined #openstack-meeting17:34
renukaDoes anyone else feel the need for this?17:34
tim-at-homerenuka, what do you mean by dynamic storage?17:35
renukatim-at-home: We do not use storage local to the nova-volume node for volumes17:36
*** jsavak has quit IRC17:36
renukaso we end up having to "add" our storage backends/arrays and remove them when they need to be offline etc17:36
tim-at-homerenuka, gotcha -17:36
DuncanTrenuka: Is this something that will end up generic, or is it better as a vendor extension?17:36
tim-at-homewont this be very specific?17:36
renukaAt the moment, the xen storage manager driver has its own table, and uses the nova-manage command to add/remove this17:37
*** jsavak has joined #openstack-meeting17:37
renukathis is how the nova-manage command looks at the moment:17:37
renukanova-manage sm backend_add <flavor label> <SR type> [config connection parameters]17:37
*** bengrue has quit IRC17:37
renukaflavor here means type (needs to be refactored)17:38
tim-at-homefor example we have a proprietary API for managing our storage - it is very specific to our particular  archtiectrure17:38
*** joesavak has quit IRC17:38
*** novas0x2a|lapto1 has joined #openstack-meeting17:38
*** jdurgin has joined #openstack-meeting17:38
*** bengrue has joined #openstack-meeting17:38
*** dendro-afk is now known as dendrobates17:38
renukaSo I guess we are leaning towards vendor extensions then17:38
*** novas0x2a|laptop has quit IRC17:39
tim-at-homeI do not feel strongly about it,17:39
DuncanTI think so. We might look at how much commonality there is later, but I don't see any advantage at the moment17:39
rnirmaleach vendor already has existing tools to manage this, should we recreate them within the context of nova17:39
renukawithout 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:41
DuncanTSurely the available storage is know dynamically by the scheduler based on what nova-volume servers present themselves?17:42
renukaright, i guess report capabilities can be used appropriately17:43
*** novas0x2a|laptop has joined #openstack-meeting17:43
renukanext up was the netapp blueprint that robert mentioned on the emails. Is anyone from netapp here?17:44
renukaguess not17:45
*** novas0x2a|lapto1 has quit IRC17:45
renukaAnything else anyone would like to bring up?17:45
*** df1 has joined #openstack-meeting17:46
DuncanTIs boot-from-volume going to be discussed at some point?17:46
renukaWe are certainly interested in that17:46
tim-at-homeis anyone using it?17:46
DuncanTThe current situation, aims and functionality is not very clear, and the current shape of the API is very limiting17:46
*** bengrue has quit IRC17:47
renukaI agree17:47
*** gyee has joined #openstack-meeting17:47
tim-at-homeme 217:47
renukaThe code seems to be there for libvirt, but I haven't used it17:47
*** novas0x2a|laptop has quit IRC17:47
tim-at-homeshould we ask Morita-san to come along?17:48
renukashould we bring this up on an email thread for visibility?17:49
tim-at-homeI think that is a good idea. I certainly find it difficult to understand exactly what is there17:50
DuncanTIt would definitely be worth getting all of the interested parties involved, yes17:50
renukaDuncanT: Is there anything in particular you would like to see in the API for example?17:50
DuncanTrenuka: I'd like to see an API for generically plugging volumes onto an instance/server  before it is booted, and setting the boot device17:51
DuncanTRather than limiting it to the ec2 boot-onto-a-cloned-copy only17:51
renukaDuncanT: there is a BootFromVolumeController in the openstack api17:52
DuncanTrenuka: I saw it, it is not clear how it is supposed to work17:52
renuka#action bring up boot from volume on email thread to get an idea of current state/goals17:53
DuncanTFor 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 volume17:53
DuncanT(or volumes)17:53
jdurginDuncanT: this exists as an OS api extension, but it could use some cleaning up17:55
*** dprince has quit IRC17:55
*** reed has joined #openstack-meeting17:55
tim-at-homeI think it would be good to consolidate the boot from volume *& the recent autocreatebootvoluems into a logical set of volume & boot capabilities17:55
renukaRight, we have about 3 minutes remaining. Anything else that needs to be brought up in the future?17:57
tim-at-homei'm good17:57
DuncanTI can't think of anything at the moment17:57
driccogood here too17:57
renukaso I noticed we have the nova volume meeting set to happen every Thursday17:58
renukajust wanted to confirm that everyone feels the need for a weekly meeting17:58
DuncanTThere have been things to discuss every week so far17:58
tim-at-homeI think at present it is a good timing,. As it happens I will be AWOL next week17:59
renukaok. let us keep it that way17:59
renukaalright, thanks everyone.17:59
*** openstack changes topic to "Openstack Meetings: | Minutes:"18:00
openstackMeeting ended Thu Nov  3 18:00:02 2011 UTC.  Information about MeetBot at . (v 0.1.4)18:00
openstackMinutes (text):
driccothanks, bye18:00
*** dendrobates is now known as dendro-afk18:00
*** adjohn has joined #openstack-meeting18:01
*** renuka has quit IRC18:02
*** jdg_ has quit IRC18:03
*** dolphm has joined #openstack-meeting18:03
*** dolphm_ has joined #openstack-meeting18:05
*** tim-at-home has quit IRC18:07
*** dolphm has quit IRC18:07
*** gyee has quit IRC18:09
*** gyee has joined #openstack-meeting18:09
*** gyee has quit IRC18:09
*** gyee has joined #openstack-meeting18:12
*** dolphm_ has quit IRC18:30
*** dolphm has joined #openstack-meeting18:31
*** cdub has joined #openstack-meeting18:40
*** darraghb has quit IRC18:42
*** clayg has joined #openstack-meeting18:42
*** clayg has left #openstack-meeting18:43
*** bengrue has joined #openstack-meeting18:44
*** novas0x2a|laptop has joined #openstack-meeting18:48
*** Gordonz_ has joined #openstack-meeting18:54
*** Gordonz_ has quit IRC18:55
*** Gordonz_ has joined #openstack-meeting18:55
*** novas0x2a|laptop has quit IRC18:57
*** Gordonz has quit IRC18:58
*** hggdh has joined #openstack-meeting19:02
*** dolphm has quit IRC19:02
*** reed has quit IRC19:02
*** adjohn has quit IRC19:05
*** adjohn has joined #openstack-meeting19:05
*** novas0x2a|laptop has joined #openstack-meeting19:09
*** mdomsch has joined #openstack-meeting19:10
*** danwent has joined #openstack-meeting19:12
*** df1 has quit IRC19:14
*** reed has joined #openstack-meeting19:14
*** reed has quit IRC19:17
*** dendro-afk is now known as dendrobates19:26
*** hggdh has quit IRC19:33
*** reed has joined #openstack-meeting19:43
*** adjohn has quit IRC19:51
*** cdub has quit IRC19:53
*** dolphm has joined #openstack-meeting19:55
*** jakedahn has quit IRC20:03
*** jakedahn has joined #openstack-meeting20:03
*** dendrobates is now known as dendro-afk20:11
*** gyee has quit IRC20:13
*** dolphm has quit IRC20:17
*** jdg has quit IRC20:23
*** bengrue has quit IRC20:29
*** jakedahn_ has joined #openstack-meeting20:31
*** jakedahn has quit IRC20:34
*** jakedahn_ is now known as jakedahn20:34
*** bengrue has joined #openstack-meeting20:43
*** Gordonz_ has quit IRC20:43
*** mdomsch has quit IRC20:49
*** jdg has joined #openstack-meeting20:52
*** jsavak has quit IRC20:56
*** gyee has joined #openstack-meeting21:02
*** adjohn has joined #openstack-meeting21:04
*** df1 has joined #openstack-meeting21:17
*** adjohn has quit IRC21:31
*** danwent has quit IRC21:39
*** reed has quit IRC22:01
*** mattray has quit IRC22:05
*** reed has joined #openstack-meeting22:19
*** danwent has joined #openstack-meeting22:31
*** adjohn has joined #openstack-meeting22:55
*** cdub has joined #openstack-meeting23:00
*** andreaf has joined #openstack-meeting23:04
*** andreaf has quit IRC23:07
*** andreaf has joined #openstack-meeting23:08
*** bhall has quit IRC23:09
*** cdub has quit IRC23:17
*** adjohn has quit IRC23:19
*** adjohn has joined #openstack-meeting23:21
*** rnirmal has quit IRC23:29
*** jdg has quit IRC23:38
*** df1 has quit IRC23:40
*** cdub has joined #openstack-meeting23:44
*** novas0x2a|laptop has quit IRC23:44
*** andreaf has quit IRC23:49
*** andreaf has joined #openstack-meeting23:50
*** cdub has quit IRC23:51
*** dendro-afk is now known as dendrobates23:55
*** andreaf has quit IRC23:55
*** andreaf has joined #openstack-meeting23:56
*** andreaf has quit IRC23:59

Generated by 2.14.0 by Marius Gedminas - find it at!