Open Stack

On Thu, 3 Mar 2011, Ed Leafe wrote:

> On Mar 3, 2011, at 10:36 AM, George Reese wrote:
>
> > It's a mistake to send OpenStack pursuing a flaw in Cloud Servers.

Boy...
   Isn't this a rat hole that I've helped us go down.
   I am completely "pro-agent" (well, more agnostic).  I would certainly
hope that the api for openstack allows for communication to an in-instance
agent, but that in-instance agent could be provided by the cloud-provider
or the instance launcher.

   The reason I piped up, and the reason I think there is some
misunderstanding is (from Ed):

> 	Again, you seem to have missed my point. OpenStack is *not* working on this.

   This is an OpenStack mailing list.  The original mail says:

| Subject: [Openstack] OS API server password generation
|
| We created a blueprint on adding support for password generation when
| creating servers. This is needed
| for Openstack API/Cloud Servers API v1.0 parity.
| ..
| https://blueprints.launchpad.net/nova/+spec/openstack-api-server-passwords
| http://etherpad.openstack.org/openstack-api-server-passwords

   So, I'm sure you can understand how people thought this was about an
openstack api specifically for setting server passwords.  I am against
that.  I think it is important to have a mechanism in the openstack api
to pass information to the guest out of band.  that information may be read
by an agent, it may be read by the android emulator running inside running
angry birds.

   My point is that it should not be
a.) "agent" specific
b.) password specific

   The original mail surely seemed to indicate that what was being
designed, on the openstack mailing list, was both a and b.

   If you read further on and go to the etherpad, it appears that the idea
is to use the xen api to push data to the guest, and have an in-instance
agent read it from there.  This is all very fine to me, and actually
mostly in line with what I suggested in my other mail.

   Scott