openstack team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Thu, 15 Dec 2011, Jesse Andrews wrote:

> 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)

See below, but I don't see a reason to call something "injected files", as
opposed to a key of:
 "files/etc/passwd" : "contents here"

and letting the guest agents and consumers sort out naming conventions.

>   * 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?

I find specific designed use like this to be unnecessary.  EC2 basically
says "heres a place to store a blob of data, do with it what you want".
>From that, best practices, good ideas, bad ideas, and even standards will
evolve.

What does a "Server Personality" give me that cannot be accomplished
accomplished by guest and lauching-entity agreeing on a key-value pair
with keyname "server-personality".

Basically, I'm saying dont bother with special keys/locations in a spec if
there is no reason to.

> >  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

Well, theres no reason it can't be plaintext either.  but, yes, thats
basically what i'm hoping for.

> >  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 :)

I dont know that its necessary is the only thing.  What is the scenario
where polling this metadata service is better than the instance polling
another network resource?  Or listening to a SQS or zookeeper, or
anything.

I agree that it seems useful (I brought it up), but I honestly can't come
up with something that it would accomplish that couldn't be done via
existing technologies just as well.

My preferences in order are:
 a.) generic key/value store metadata service, that can be populated on
     instance creation.
 b.) allow get/set/delete from api
 c.) allow get/set/delete from in-instance (note, though, that can
     actually be accomplished via the same path as 'b', there is no reason
     credentials can't/shouldn't exist in the instance).

I really think that everything you or I would want to accomplish can be
done given those fundamentals.