openstack team mailing list archive

[Paul Voccio <paul.voccio@xxxxxxxxxxxxx>]

Scott,

I completely understand your point of view and were you are coming from. I
think you concerns are absolutely valid. That said, there isn't a required
agent feature to do anything yet. We're not designing anything behind any
doors and tossing it over the fence for other people to deal with. Some
people were asking us for the code that we already have. As I've stated
before, it currently works for XenServer and we want extend this to be
hypervisor agnostic and a networked service. Nothing is or will be changed
'willy-nilly'.
 
I'm not proposing *any* api for a hypothetical service at this point. That
needs to have it own BP, be vetted, and services built around this.

Since the code is coupled with Nova and Xen at the moment, the ask was
should it be included and where? As Vish stated, its extremely simple to
pull it out and move it to a metadata project when appropriate.

I would like to continue the conversation around a metadata service and
what it could look like. I think its a solution we can all benefit from.

Pvo



On 2/11/11 3:18 PM, "Scott Moser" <smoser@xxxxxxxxxx> wrote:

>On Fri, 11 Feb 2011, Paul Voccio wrote:
>
>> Below.
>>
>> On 2/11/11 2:30 PM, "Scott Moser" <smoser@xxxxxxxxxx> wrote:
>>
>> >On Fri, 11 Feb 2011, Vishvananda Ishaya wrote:
>> >
>> >> Agreed.  By default lets put things into nova because it makes
>> >> development and visibility much easier.  As eric mentioned, we can
>> >> always break it out later.
>> >
>> >The stability of the API for communication between the hypervisor
>>platform
>> >and an instance is very important.  The ability to quickly change it
>> >should not be the primary reason that you decide where to land the
>>code.
>> >
>> >Once you're past the immediate bringup, you're going to need to
>>maintain
>> >backward compatibility.  You'll have images running on openstack
>> >installations that have old versions of the agent, and no real option
>>to
>> >modify them.  You need to get this right, and minimal is better.
>>
>> One of the features of the agent is to return features is knows about
>>and
>> return a 'not implemented' if it gets a request it can't complete.
>>Another
>> feature of the agent is to be passed an option to update itself, given a
>> url and a md5 hash.
>
>So thats a required feature of all potential agents ?  It was initially
>stated that the agent was necessary to setup networking.
>I assume that 'url' above could potentially be cdrom://foo.bar.gz ,
>though.
>
>Either way, I surely hope that your argument is not suggesting that
>you can change the API willy-nilly because all the agents in existing
>guests should just be able to update themselves.
>
>Another thing that Amazon did well, was their host->guest communication,
>which takes place as the "metadata service" is entirely versioned.  Ie:
>
>$ wget http://instance-data/ -O - -q; echo
>1.0
>2007-01-19
>2007-03-01
>2007-08-29
>2007-10-10
>2007-12-15
>2008-02-01
>2008-09-01
>2009-04-04
>2011-01-01
>latest
>
>Each version is maintained indefinitely.  I realize that their metadata
>service is simple, but again, other than networking setup, I really think
>its completely sufficient.
>
>I don't see a necessity for making a lot of complex interactions between
>hypevisor and guest. All that does is  make it more difficult to develop
>guests.
>
>I won't object much more, but please, please keep the guest requirements
>and expectations to a minimum.  I'm involved in the development of images
>for such a platform, and I do not want to be limited by expectations that
>the host has upon our images.