Open Stack

Preamble:

Until now, all data that is made available by the metadata server has been
data that cannot be found anywhere else at the time it may be needed.

In short, an instance can't be passed it's instance id before it's instance
id has been allocated so a user cannot pass it to an instance that is being
started up.  So whether a user wants to jump through a few hoops or not to
pass their instance the instance id of itself... they simply cannot without
metadata api being there to provide it at creation time.

This means that the metadata server holds an uneasy place as a necessary
clearing house ( evil? ) of data that just doesn't have another place to
be.  It's not secure, it's not authenticated, and it's a little scary that
it exists at all.

I wish to add some data to the metadata server that can be found somewhere
else.  That a user could jump through a hoop or two to add to their
instances.  Esteemed personages are concerned that I would be crossing the
rubicon in terms of opening up the metadata api for wanton abuse.  They are
not without a right or reason to be concerned.  And that is why I am going
to attempt to explicitly classify a new category of data that we might wish
to allow into the metadata server.  If we can be clear about what we are
allowing we can avoid abuse.

I want to provide a uniform ( standardized? ) way for instances in the
openstack cloud to communicate back to the OpenStack APIs without having to
be provided data by the users of the cloud services.  Today the mechanism
by which this is done is catastrophically difficult for a new user.

This uniform way for instances to interact with the openstack API that I
want already sort of exists in the keystone catalog service.  The problem
is that you need to know where the keystone server is in the world to
access it.  That of course changes from deployment to deployment.
Especially with the way SSL endpoints are being handled.

But the metadata API server is generally known as it uses a default ip
address value that can be found on any amazon compatible deployment.  In
fact to my knowledge it is the only known way to query openstack for data
relevant to interacting with it without user interaction.  And that's the
key to this whole thing.  I want to direct users or automation baked into
instances to the keystone api and catalog service.  And the only way I know
how to do that is the metadata service.

This api data can be classified as being first and foremost OpenStack
infrastructure related.  Additionally it is not available without a user
providing it anywhere else.  And finally it is a catalog service.

I'd love some more input on whether this makes sense, or can be improved
upon as an idea and formalized as a rule for using the metadata api without
abusing it.

Cheers,

   Matt Joyce

PS:

My current work effort in regards to this is related to passing keystone
credentials to instances via pam authentication.  So I can do a number of
API related queries into openstack because I have credentials available to
the OS that are dynamically allocated.  But to make my image portable I
need to not be baking in the keystone API URI.

If that gives any insight on why this is important to me.  Or possibly you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120721/352154f3/attachment.html>