<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">FWIW, an early proposal to address this, as well as capability discovery, still lives at <a href="https://etherpad.openstack.org/p/api-version-discovery-proposal" target="_blank">https://etherpad.openstack.org/p/api-version-discovery-proposal</a>.  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.</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">On Thu, Feb 13, 2014 at 6:50 AM, Jamie Lennox <span dir="ltr"><<a href="mailto:jamielennox@redhat.com" target="_blank">jamielennox@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">6. GET '/' is unrestricted. GET '/vX' is often token restricted.<br>
</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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.<br>

</blockquote><div><br></div><div>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.</div>

<div><br></div><div>And this doesn't even touch on the SC endpoints that include things like tenant/project id...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


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?<br></blockquote>

<div><br></div><div>* 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 </div>

<br></div><div class="gmail_quote">* 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.</div>

<div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">There are two transitional things to also consider:</div><div class="gmail_quote"><br></div><div class="gmail_quote">* 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.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">* 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 <a href="https://localhost:5000/v2.0">https://localhost:5000/v2.0</a>.  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?</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">dt</div><div class="gmail_quote"><br></div>-- <br><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br>
</div></div>