Open Stack

Hi all, I am in firm believe that all network and VM provisioning should
happen outside core via an API to one of possibly many Networking and or
VM Client modules (we are about to release a blueprint for a complete
external network handling module). There can never be full detachment in
the sense that the networking and vm capabilities have to be defined
inside core and that the external  module with either understand all of
or some subset of. The point I am making here is that the moment you put
these types of features directly into core you are locked into that one
module or you bloat to encompass many modules. In either case you risk
breaking core each time you adjust or add one of these modules. This is
simply the wrong way to do this an goes against everything modular I had
heard in the Texas design summit.


Sincerely,
Aimon
 

On 2/11/11 1:18 PM, Scott Moser wrote:
> On Fri, 11 Feb 2011, Paul Voccio wrote:
>
>> Below.
>>
>> 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.
> 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.
>
> _______________________________________________
> 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

-- 
Aimon Bustardo | Morph Labs | +1.310.625.0608 (mobile) | +1.310.437.4898 (office) | www.morphlabs.com | aimon at mor.ph