openstack team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Thu, 15 Dec 2011, Jesse Andrews wrote:

> Great question.
>
> Right now there are 3 approaches to metadata/runtime config:
>
>  * ec2 metadata service - http://169.254.169.254/ (used by ubuntu's
> cloud-init for example)
>  * config drive - added in diablo
>  * xenstore via openstack agent - https://launchpad.net/openstack-guest-agents
>  * injecting files into the filesystem prior to launch - on some
> hypervisors / filesystems combinations
>
> There are issues with each approach currently:
>
>  * metadata service - requires that cloud uses DHCP to configure network
>  * config drive - only sets values at runtime and no support from any guests
>  * xenstore approach - hypervisor specific.
>  * injecting into filesystem - brittle as it requires the host to
> support arbitrary filesystems
>
> If we assume that instance networking can be configured by DHCP, then
> a metadata service is probably our best choice for simplicity of
> implementation and user experience.
>
> Given that Rackspace Public Cloud is the only openstack developer/user
> (I know of) that doesn't use DHCP for network configuration of
> instances, I reached out to the team to see if DHCP would be an
> option.  They are researching either a way use DHCP _or_ propose an
> approach to initial network configuration that can be executed by the
> openstack guest agent.
>
> Based on those conversations we've been writing a proposal that would
> recommend guests use a (currently non-existing) openstack metadata api
> - http://wiki.openstack.org/guest-configuration

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.

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