On Thu, Dec 15, 2011 at 8:43 AM, Scott Moser <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
