openstack team mailing list archive

[John Garbutt <John.Garbutt@xxxxxxxxxx>]

One use case is providing metadata to an instance before that instance starts their network stack. A bit of an edge case, but I guess one instance of this use case is the network injection logic used for Flat networking.

Would injected files cover the above case? Would it still work after the proposed changes?

I guess it should work, assuming nova injects the files in the same way it does for injecting network configuration, rather than relying on the agent to write the files once the system has booted by getting data from the metadata service. 

Maybe this is what the configuration drive could be used for (assuming either the agent isn't responsible for correctly mounting the configuration drive, or it can mount the disk before it has access to any network)?

Thanks,
John

> -----Original Message-----
> From: openstack-bounces+john.garbutt=eu.citrix.com@xxxxxxxxxxxxxxxxxxx
> [mailto:openstack-bounces+john.garbutt=eu.citrix.com@xxxxxxxxxxxxxxxxxxx]
> On Behalf Of Vishvananda Ishaya
> Sent: 15 December 2011 22:50
> To: Scott Moser
> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] Metadata and File Injection
> 
> 
> 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_Pe
> >> rsonality-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_Me
> >> tadata-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/MetadataS
> >> ection.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
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp