Open Stack

On Thu, 3 Mar 2011, George Reese wrote:

> Of all the boostrapping mechanisms I have encountered, the AWS model
> still remains the best. Specifically, with the guest OS pulling the keys
> from a trusted platform source.
>
> Any mechanism that requires an agent or requires any ability of the
> hypervisor or cloud platform to inject a password creates trust issues.
> In particular, the hypervisor and platform should avoid operations that
> reach into the guest. The guest should have the option of complete
> control over its data.

I completely agree with this.

Generally, I can think of only 2 real needs of openstack in this regard.
a.) needs to be able to accept some blob of data in the launch-instance
    API call, and make that data available to the instance in a private
    channel (such as the xen store).
b.) needs to be able to read data that the instance writes to that channel
    and pass that data back through to a user who invokes some API call.

Amazon gets along fairly well with just 'a' (the metadata service and
'user-data').  Additionally, theres is 1 time write only (you can only
specify user-data on instance start, and cannot change it... other than
with an instance stop and start).

You can get by by simple api that allows the entity that launches the
instance to make data available to the instance, and stop there.
If you take a list of key and values that can be put in, it would even be
better.  For example,
ec2 looks like this:
 $ ec2-run-instance  ami-abcdeg --user-data="my. data here"
The open stack could look like this:
 $ openstack-run-instance \
   --data-user-data="my. data here"
   --data-admin-data="some other data here"

The end result of which would be the metadata service having
  <source>/user-data  : "my. data here"
  <source>/admin-data : "some other data here"

In EC2 terms, what i'm really hoping for would be:
  http://169.254.169.254/latest/user-data
  http://169.254.169.254/latest/admin-data

I think this is very powerful, and allows Rackspace to implement their
initial password setting very easily via an installed guest agent.

Ie, the guest comes up, the agent grabs
   http://169.254.169.254/latest/guest-agent-data
that contains
   root_password : foo
   other-data here
   and more here
   it doesn't materr

And then sets the root password.

The above is very generic, easily re-purposed, and carries along the
legacy Amazon user-data very easily.  If you also make that data able to
be updated via an API call, then you're even better off.  That would allow
the launcher to set the root password, verify it can get in to the
instance, and then clear that data from the store so that it couldn't be
seen again.

Scott


== small note ==
My primary interest in the key/value rather than just "value" in a single
"user-data" (as Amazon has it) is that then only 1 party really has
complete control of that user-data.  For example, again, in the EC2 world,
Rightscale wants to inject some data into the instance, and the user wants
to inject some data into the instance.  But both of these have to be
shoved into that one 'user-data' field.  So, you have to end up putting a
multipart blob of data there and making both consumers aware that
http://169.254.169.254/latest/user-data will not have exactly what they
launched the instance with.