openstack team mailing list archive

[Jesse Andrews <anotherjesse@xxxxxxxxx>]

On Thu, Dec 15, 2011 at 8:43 AM, Scott Moser <smoser@xxxxxxxxxx> wrote:
> I'm just curious, what are the motivations behind inventing something
> other than the EC2 Metadata service?  It is generally functional, and
> quite a lot can (and has) built atop this simple service.

I should clarify - the idea is that ec2 metadata service is a great
starting point - but there are already a handful of additions that
should be added.

In the existing (ec2) metadata service the urls look like:

   http://169.254.169.254/(version)/(resource)

My hope is that we can add features like:

  * injected files / personality (or you can think of them as multiple
named userdata sections)
  * updatable metadata params (the key/value params in the openstack
api) with CRUD (so you can remove/update from guest)

> Secondly, There are 2 features that I feel are missing from the metadata
> service.  And I'd hope that these could be accounted for if there is going
> to be invention done.
>  a.) user-data is a single entity.
>     There are potentially multiple sources that want to provide input to
>     a guest (the end user might want to install some packages at boot,
>     and the cloud infrastructure might want to tell the guest of a local
>     mirror).  cloud-init supports multipart-mime in userdata, so that
>     there can be separate pieces inside that single source, but even
>     then, all parties involved have to agree that they do not completely
>     "own" that resource.

The multipart-mime stuff is a great hack but isn't very user friendly
as you state.

In the openstack api we have "server personalities" that are similar
to userdata except you can have multiple of them and they are named.
http://docs.openstack.org/api/openstack-compute/1.1/content/Server_Personality-d1e2543.html

If the guest (client) is in charge of pulling the "personality" data
instead of the host injecting it, would this fulfill the usecase?

>  b.) There is no way to disable it.
>     cloud-init supports writing a null-route to the metadata service,
>     which can make it inaccessible to any non-root entity on the system.
>     However, it would be nicer if there was a way to disable it entirely.
>     With that in place, passing credentials into the guest would be
>     easier as once they're consumed they can be removed.

The usecase of passing credentials is one reason we want to have the
metadata passed via the openstack API mutable via the metadata service

  http://docs.openstack.org/api/openstack-compute/1.1/content/Server_Metadata-d1e2529.html

A hashed password could be provided to the guest via the metadata
service in a key "bcrypt_password".  The guest agent could retrieve
the password and then DELETE it:

   curl -X DELETE http://169.254.169.254/os/meta/bcrypt_password

>  c.) No way to modify contents of the service after instance launch.
>     OK, I said 2 features, and really this one is wishlist.  If we had an
>     arbitrary key-value store that was available, the user could interact
>     with the guest using this service.  It'd have to be poll-based, but a
>     in-guest hypervisor could watch for creation and deletion of keys.
>     Potentially, the MD might be RW from inside guest, meaning it could
>     even convey information back.
>     I consider this wishlist because really, there are perfectly good
>     solutions for communicating to in-guest agents, theres not a lot of
>     reason to invent a new one.

The openstack API already has CRUD of the key/value metadata in the
non-metadata (regular) API.

     http://docs.openstack.org/api/openstack-compute/1.1/content/MetadataSection.html

By exposing this through the metadata service I think we get what you
are asking for.

My wishlist is the able to do long-polling against the metadata
service to be alerted of changes from the guest :)

Jesse