openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On 07/21/2012 09:00 PM, Matt Joyce wrote:
> 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 is only due to the asinine EC2 API -- or rather the asinine
implementation in EC2 that doesn't create an instance ID before the
instance is launched.

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

Agreed. I wish people didn't use the EC2 API at all, since it's a
complete bag of fail and a beautiful example of a terribly thought-out
API. That said, the OpenStack Compute API v2 has its share of pockmarks
to be sure.

But... unfortunately, if you're going to use the EC2 API this hard-coded
169.254.169.254 address is what we have to deal with.

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

Let's be clear here... are you talking about the OpenStack Compute API
or are you talking about the OpenStack Metadata service which is merely
the EC2 Metadata API? We already have the config-drive extension [1]
that allows information and files to be injected into the instance and
loaded as a readonly device. The information in the config-drive can
include things like the Keystone URI for the cell/AZ in which an
instance resides.

> Today the
> mechanism by which this is done is catastrophically difficult for a new
> user.

Are you specifically referring here to the calls that, say, cloud-init
makes to the (assumed to be running) EC2 metadata API service at
http://169.254.169.254/latest/? Or something different? Just want to
make sure I'm understanding what you are referring to as difficult.

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

This can be done using config-drive and the OpenStack community coming
up with a standard file or tool that would be injected into the config
drive. This would be similar to the calls currently executed by
cloud-init that are hard-coded to look for 169.254.169.254. Would that work?

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

As mentioned above, config-drive extension was built for just this
purpose IIRC. Chris Macgown, who wrote the original extension, cc'd,
should be able to comment on this further.

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

Well, we know we can't change the EC2 Metadata API since we don't own or
have any control over the Amazon APIs. We can however come up with an
OpenStack-centric tool using config-drive and a tool that would query a
Keystone endpoint for a local OpenStack Compute API endpoint and then
use the existing OpenStack Compute API calls for server metadata [2]?

That sounds doable to you?

Best,
-jay

[1] Config Drive extension:
http://docs.openstack.org/developer/nova/api_ext/ext_config_drive.html
[2] Server metadata calls in Compute API:
http://docs.openstack.org/api/openstack-compute/2/content/List_Metadata-d1e5089.html


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