openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

On Dec 15, 2011, at 10:37 AM, Scott Moser wrote:

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

I think you are stating the same thing here.  Basically repurposing the existing personality code to be
key, value
instead of
filename, data

If the guest agent wants to interpret keys as filenames it can.
we could repurpose metadata as well, but it multiple key/value with potentially large values seems ideal.

> 
> 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._______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp