openstack team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

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.