[Openstack] xen server agent code in nova?
paul.voccio at rackspace.com
Fri Feb 11 20:44:34 UTC 2011
On 2/11/11 2:30 PM, "Scott Moser" <smoser at ubuntu.com> 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.
>The separation would make you think about things more. Ie, with the
>project internal, you'll have basically an internal api, that can be
>changed at will. With it external, you'll be relying on your published
>API to be somewhat stable.
>I suspect that I will lose this argument, and I can't pretend that I have
>much grounds for complaint as I've not spoken about anything else. This
>is something I belive Amazon did very well. Other than the fact that
>their metadata service really relies on dhcp, its is entirely sufficient,
>and *very* minimal.
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack at lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help : https://help.launchpad.net/ListHelp
More information about the Openstack