Open Stack

FWIW, an early proposal to address this, as well as capability discovery,
still lives at
https://etherpad.openstack.org/p/api-version-discovery-proposal.  I've lost
track of where this went, and even which design summit this is from, but
I've been using it as a sanity check for the discovery bits in OSC.

On Thu, Feb 13, 2014 at 6:50 AM, Jamie Lennox <jamielennox at redhat.com>wrote:

> 6. GET '/' is unrestricted. GET '/vX' is often token restricted.
>

> Keystone allows access to /v2.0 and /v3 but most services give a HTTP
> Unauthorized. This is a real problem for discovery because we need to be
> able to evaluate the endpoints in the service catalog. I think we need to
> make these unauthorized.
>

I agree, however from a client discovery process point-of-view, you do not
necessarily have an endpoint until after you auth and get a service catalog
anyway.  For example, in the specific case of OpenStackClient Help command
output, the commands listed may depend on the desired API version.  To get
the endpoints to query for version support still requires a service catalog
so nothing really changes there.

And this doesn't even touch on the SC endpoints that include things like
tenant/project id...


> Please have a look over the wiki page and how it addresses the above and
> fits into the existing schemes and reply with any comments or problems that
> you see. Is this going to mess with any pre-existing clients?
>

* id: Let's either make this a real semantic version so we can parse and
use the major.minor.patch components (and dump the 'v') or make it an
identifier that matches the URL path component.  Right now

* updated: I think it would be a friendly gesture to update this for
unstable changes as the id is likely to not be updated mid-stream.  During
debugging I would want to be able to verify exactly which implementation I
was talking to anyway.


There are two transitional things to also consider:

* We have to produce a discovery mechanism that takes in to account the
historical authentication URLs published by deployments that include a
version.  ayoung's Ml thread last week discussed this a bit, we should
document the approaches that we're testing and why they do or do not work.

* There are real-world deployments that do not configure admin_endpoint
and/or public_endpoint in keystone.conf.  Discovery is really useless if
the URL you are given is https://localhost:5000/v2.0.  Do we need to talk
about another horrible horrible hack to deal with these or are these
deployments going to be left out in the cold?

dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140213/fedbab65/attachment.html>