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 <jamielen...@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 dtro...@gmail.com
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev