Mailing List Archive: OpenStack: Dev

[nova] a proposal to change metadata API data

Index | Next | Previous | View Threaded

matt.joyce at cloudscaling

Jul 21, 2012, 6:00 PM

Post #1 of 12 (287 views)
Permalink

[nova] a proposal to change metadata API data

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.

jaypipes at gmail

Jul 23, 2012, 1:17 PM

Post #2 of 12 (265 views)
Permalink

Re: [nova] a proposal to change metadata API data [In reply to]

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 [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

matt.joyce at cloudscaling

Jul 23, 2012, 2:25 PM

Post #3 of 12 (266 views)
Permalink

Re: [nova] a proposal to change metadata API data [In reply to]

> 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.
>
>
Agreed on all counts.

> > 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.
>
>
I mean the OpenStack Metadata service. The config drive extension does not
as far as I am aware produce a "uniform" path for data like this. This API
query should be the same from openstack deployment to openstack deployment
to ensure portability of instances relying on this API query to figure out
where the catalog service is. By "uniform" I mean it has all the love care
and backwards versioning support as a traditional API query. The
config-drive seems more intended to be user customized rather than
considered a community supported API query.

> > 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.
>
>
I am referring to the whole new user experience. Anything custom to a
deployment of openstack is now outside of our control and is not portable.
Also a new user will not be prepared to inject user data properly. Going
further and a bit onto an irate tangent. Horizon has a really round about
and completely non intuitive way of providing users with info on where API
servers are. IE you have to generate an openstack credentials file.
download it. and look at it in a text editor and then know what it is you
are looking at. To find your tenant_name you have to guess in the dark
that horizon is referring to your tenant name as a project. The whole
thing is insane. What I am talking about here is a first step in allowing
image builders to integrate into openstack in a uniform way across all
installations ( or most ). And that will allow people to reduce the
overall pain on new users of cloud at their pleasure. I am asking for this
based on my experience trying to do this outside of openstack development.

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

I don't know. I'd say maybe. But I'd prefer it was tracked as an API
call. It will have in that area legitimate support from the community and
backwards version compatibility requirements. I think ultimately it
belongs in the API as much as any other query. While I think this sort of
solves the issue and may smooth a few folks feathers about the issue. I
think it's probably the wrong way to handle it and likely to bite us in the
ass down the road when someone starts mangling that file or doesn't realize
config-drive is a dependency for that sort of fundamental query.

> > 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.
>
>
I disagree on that being the purpose. I think the config drive is a user
customization option. In this case I am talking openstack community
support like any other API query we support. As far as I can tell placing
it as part of config-drive robs it of that. And that's unacceptable for
people wanting to use that query for code baked into images.

> > 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?
>
>
Not as it currently exists. Unless config-drive is going to be held to the
same standard as an API query set. And currently it may be in terms of
actually development support... but there is no authoritative community
promise to that.

I get the argument for using config-drive. And to be blunt I think it's
probably superior to the metadata API on a number of things. But it's only
functional in some reduced set of openstack deployments, it's not held to
the same level of scrutiny as an API query set. And that means it's not
going to be usable today. It means it MIGHT be usable sometime in the
future maybe but as of now probably not.

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

jaypipes at gmail

Jul 24, 2012, 6:20 AM

Post #4 of 12 (269 views)
Permalink

Re: [nova] a proposal to change metadata API data [In reply to]

Thanks Matt, comments inline...

On 07/23/2012 05:25 PM, Matt Joyce wrote:
> > 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.
>
> I mean the OpenStack Metadata service.

Sorry, I'm still confused. The only actual stand-alone service in
OpenStack for metadata is the OpenStack EC2 Metadata service that runs
on the fixed AWS 169.254.169.254 address. Are you referring to this, or
are you referring to the /servers/<SERVER_ID>/metadata call in the
OpenStack Compute API v2?

> The config drive extension does
> not as far as I am aware produce a "uniform" path for data like this.

Absolutely correct. The community would need to come to a consensus on
this uniformity, just as Amazon came to the decision to hard-code the
169.254.169.254 address.

> This API query should be the same from openstack deployment to openstack
> deployment to ensure portability of instances relying on this API query
> to figure out where the catalog service is. By "uniform" I mean it has
> all the love care and backwards versioning support as a traditional API
> query.

Agree completely.

> The config-drive seems more intended to be user customized
> rather than considered a community supported API query.

Well, that may be the case, but as mentioned above, I think we could
*use* config-drive along with a community consensus on a uniform place
to store lookup information for a real OpenStack metadata service --
things like a private key, info file containing the IP of the "nearest"
metadata service, etc...

>
> > 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.
>
> I am referring to the whole new user experience. Anything custom to a
> deployment of openstack is now outside of our control and is not
> portable.

Sure, completely agree!

> Also a new user will not be prepared to inject user data
> properly.

Well, I'm actually not suggesting having the user really be involved at
all with the injection of keys/information into the config-drive :) That
would done by Nova.

When a user currently launches an image in OpenStack, that image
connects to the EC2 metadata service automatically if cloud-init is
installed in the image. I am picturing a similar scenario for this
config-drive stuff -- only instead of cloud-init needing to be installed
on the image, I'm suggesting Nova create a "standard" (uniform)
config-drive (or part of a config-drive) that contained upstart/startup
scripts, keys, and info for connecting to some OpenStack Metadata service.

> Going further and a bit onto an irate tangent. Horizon has a
> really round about and completely non intuitive way of providing users
> with info on where API servers are. IE you have to generate an
> openstack credentials file. download it. and look at it in a text
> editor and then know what it is you are looking at. To find your
> tenant_name you have to guess in the dark that horizon is referring to
> your tenant name as a project.

Heh, well, you know where I stand on the whole tenant vs. project theme
:) That said, it's a bit of a tangent, as you admit to above :)

> The whole thing is insane. What I am
> talking about here is a first step in allowing image builders to
> integrate into openstack in a uniform way across all installations ( or
> most ). And that will allow people to reduce the overall pain on new
> users of cloud at their pleasure. I am asking for this based on my
> experience trying to do this outside of openstack development.

See my suggestion above... maybe we're getting closer towards a
commonly-envisioned solution? Snipping the rest of the conversation
because I basically agree with most of what you're saying.

Best,
-jay

> > 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?
>
>
> I don't know. I'd say maybe. But I'd prefer it was tracked as an API
> call. It will have in that area legitimate support from the community
> and backwards version compatibility requirements. I think ultimately it
> belongs in the API as much as any other query. While I think this sort
> of solves the issue and may smooth a few folks feathers about the
> issue. I think it's probably the wrong way to handle it and likely to
> bite us in the ass down the road when someone starts mangling that file
> or doesn't realize config-drive is a dependency for that sort of
> fundamental query.
>
>
> > 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.
>
>
> I disagree on that being the purpose. I think the config drive is a
> user customization option. In this case I am talking openstack
> community support like any other API query we support. As far as I can
> tell placing it as part of config-drive robs it of that. And that's
> unacceptable for people wanting to use that query for code baked into
> images.
>
>
> > 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?
>
>
> Not as it currently exists. Unless config-drive is going to be held to
> the same standard as an API query set. And currently it may be in terms
> of actually development support... but there is no authoritative
> community promise to that.
>
> I get the argument for using config-drive. And to be blunt I think it's
> probably superior to the metadata API on a number of things. But it's
> only functional in some reduced set of openstack deployments, it's not
> held to the same level of scrutiny as an API query set. And that means
> it's not going to be usable today. It means it MIGHT be usable
> sometime in the future maybe but as of now probably not.
>
>
> 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
> <https://launchpad.net/%7Eopenstack>
> > Post to : openstack [at] lists
> <mailto:openstack [at] lists>
> > Unsubscribe : https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> > More help : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> Post to : openstack [at] lists
> <mailto:openstack [at] lists>
> Unsubscribe : https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> More help : https://help.launchpad.net/ListHelp
>
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

smoser at ubuntu

Jul 24, 2012, 7:55 AM

Post #5 of 12 (259 views)
Permalink

Re: [nova] a proposal to change metadata API data [In reply to]

On Sat, 21 Jul 2012, 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 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

Thank you for using 'Esteemed' rather than 'no good @#@$! %!$@$ %#%#%#%',
which I'm sure you considered.

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

As Jay was confused, I think we really need to separate the notion of "EC2
API" and "EC2 Instance Metadata API". Right now, nova is *very* usable
without use of the external EC2 API. It is much more dependent on the
Instance Metadata API.

Config drive is one alternative to the EC2 metadata service.

Matt's mail discusses only the "Instance Metadata API"

I had a blueprint at the last summit that covered making config-drive and
the ec2 metadata service basically contain the same data.
http://etherpad.openstack.org/FolsomNovaConfigDriveImprovements

The general idea there was to replace the current config-drive format with
basically a rendering of the data found in the metadata service. This
proposal met with surprisingly little complaint. I planned on then also
extending that by adding to both the metadata service and the config-drive
"openstack metadata content".

This bit of information that Matt is interested in would fit under the
openstack metadata content. But would not be available under the EC2
data.

My plan for backwards compatibility was basically that we would make:
* http://169.254.169.254/ : look just like the ec2 metadata like thing
that we have now in nova. A request here would dump the same content
it currently does, which is a list of YYYY-MM-DD versions.
* http://169.254.169.254/ec2 point to http://169.254.169.254/
* http://169.254.169.254/openstack/ be the well known location of the
openstack metadata service.

The config drive basically then looks just like the metadata service.

We then have to define the content that we have at that exists at
/openstack, basically creating the first version of the openstack metadata
service api. I personally see nothing wrong with YYYY-MM-DD for a
version, as it sorts so well, and is generally immediately understood what
it means.

I planned to simply have the top level entry list versions available
just like the EC2 one does. Ie, It would have something like:
2012-07-25
latest
A request to http://169.254.169.254/openstack/2012-07-25 would return
JSON formatted data. That data would have things like:
instance-id
ami-id
keystone-endpoint <-- for Matt

What I said to Matt was that I think we need to consider (and scrutinize)
changes to the data available in the openstack metadata service the same
way we would an API change.

My choice of the keyname 'keystone-endpoint' is probably bad, but in
making a bad choice, it shows the value in making good choices, which
aren't made without thought and deliberation.

I simply haven't gotten around to doing the work above. If someone else
wants to take a stab at it, I'd love to help and work together on it.

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

I promised Matt I would not complain, so my comments here have been deleted. :)

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

matt.joyce at cloudscaling

Jul 24, 2012, 9:17 AM

Post #6 of 12 (260 views)
Permalink

Re: [nova] a proposal to change metadata API data [In reply to]

Scott thanks =P

martin.packman at canonical

Jul 24, 2012, 9:47 AM

Post #7 of 12 (258 views)
Permalink

Re: [nova] a proposal to change metadata API data [In reply to]

On 23/07/2012, Jay Pipes <jaypipes [at] gmail> wrote:
>
> 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.

So, I'm curious, how do you allocate a server id in advance using the
openstack api so you can pass it in rather than relying on an external
metadata service? I've not seen anything in the documentation
describing how to do that.

Martin

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

jaypipes at gmail

Jul 24, 2012, 10:03 AM

Post #8 of 12 (259 views)
Permalink

Re: [nova] a proposal to change metadata API data [In reply to]

On 07/24/2012 12:47 PM, Martin Packman wrote:
> On 23/07/2012, Jay Pipes <jaypipes [at] gmail> wrote:
>>
>> 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.
>
> So, I'm curious, how do you allocate a server id in advance using the
> openstack api so you can pass it in rather than relying on an external
> metadata service? I've not seen anything in the documentation
> describing how to do that.

The OpenStack Compute API POST /servers command creates a server UUID
that is passed back in the initial response and allows the user to query
the status of the server throughout its launch sequence.

http://docs.openstack.org/api/openstack-compute/2/content/CreateServers.html

-jay

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

martin.packman at canonical

Jul 24, 2012, 10:10 AM

Post #9 of 12 (266 views)
Permalink

Re: [nova] a proposal to change metadata API data [In reply to]

On 24/07/2012, Jay Pipes <jaypipes [at] gmail> wrote:
>
> The OpenStack Compute API POST /servers command creates a server UUID
> that is passed back in the initial response and allows the user to query
> the status of the server throughout its launch sequence.

I'm not really seeing how that improves on the situation compared to
the EC2 api. If a server needs to know its own id, it must either
communicate with an external service or be able to use the compute
api, which means putting credentials on the instance. Or am I missing
a trick?

Martin

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

jaypipes at gmail

Jul 24, 2012, 10:26 AM

Post #10 of 12 (260 views)
Permalink

Re: [nova] a proposal to change metadata API data [In reply to]

On 07/24/2012 01:10 PM, Martin Packman wrote:
> On 24/07/2012, Jay Pipes <jaypipes [at] gmail> wrote:
>>
>> The OpenStack Compute API POST /servers command creates a server UUID
>> that is passed back in the initial response and allows the user to query
>> the status of the server throughout its launch sequence.
>
> I'm not really seeing how that improves on the situation compared to
> the EC2 api. If a server needs to know its own id, it must either
> communicate with an external service or be able to use the compute
> api, which means putting credentials on the instance. Or am I missing
> a trick?

All I am saying is that Nova knows the instance's ID at the time that a
config-drive can be created and installed into the instance. You can't
do that with the "user data" EC2 API stuff, but you can with
config-drive. Which is why I was recommending using config-drive.

Best,
-jay

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

matt.joyce at cloudscaling

Jul 24, 2012, 11:04 AM

Post #11 of 12 (272 views)
Permalink

Re: [nova] a proposal to change metadata API data [In reply to]

What I am doing is putting credentials into user sessions on the instance.

-Matt

On Tue, Jul 24, 2012 at 10:10 AM, Martin Packman <
martin.packman [at] canonical> wrote:

> On 24/07/2012, Jay Pipes <jaypipes [at] gmail> wrote:
> >
> > The OpenStack Compute API POST /servers command creates a server UUID
> > that is passed back in the initial response and allows the user to query
> > the status of the server throughout its launch sequence.
>
> I'm not really seeing how that improves on the situation compared to
> the EC2 api. If a server needs to know its own id, it must either
> communicate with an external service or be able to use the compute
> api, which means putting credentials on the instance. Or am I missing
> a trick?
>
> Martin
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>

matt.joyce at cloudscaling

Jul 24, 2012, 11:15 AM

Post #12 of 12 (260 views)
Permalink

Re: [nova] a proposal to change metadata API data [In reply to]

> All I am saying is that Nova knows the instance's ID at the time that a
> config-drive can be created and installed into the instance. You can't
> do that with the "user data" EC2 API stuff, but you can with
> config-drive. Which is why I was recommending using config-drive.
>
> Best,
> -jay
>
>
For the record. I don't like the idea of requiring instances to modify
their file systems just to get access to this sort of data. I think it's a
great option, but as a requirement I think it totally sucks.

-Matt

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads