<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Adam Young" <ayoung@redhat.com><br><b>To: </b>openstack-dev@lists.openstack.org<br><b>Sent: </b>Wednesday, February 5, 2014 2:29:18 AM<br><b>Subject: </b>Re: [openstack-dev] Ugly Hack to deal with multiple versions<br><div><br></div><div class="moz-cite-prefix">On 02/04/2014 11:09 AM, Dean Troyer
wrote:<br></div><blockquote cite="mid:CAOJFoEtyGs8wP3XJ1ooyqgy_AwA_csF5wHCVD=aX_JjXefvOLA@mail.gmail.com"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 4, 2014 at 9:00 AM, Sean
Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span>
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Can you be more specific about what goes wrong here? I'm
not entirely<br>
sure I understand why an old client of arbitrary age needs
to be<br>
supported with new OpenStack. The contract is the API, not
the client,<br>
and an old client that doesn't do version discovery is
just a buggy<br>
client from what I'm concerned. Time to release a new
version.<br></blockquote><div><br></div></div></div></div></blockquote><br>
Remember: the client is not the only code that Keystone has to
worry about. THere is also a whole cotteage industry that is
talking direct to the endpoints themselves. We've trained these
poor souls to expect the version in the Endpoint. So even if we
said "we are only supporting the latest Keystone client" we'd
still have to deal with code that expects the identity endpoint URL
to look like this:<br><br><a class="moz-txt-link-freetext" href="https://hostname:35357/v2.0/" target="_blank">https://hostname:35357/v2.0/</a><br><br>
We want people to be able to call on the V3 API. To be able to do
version discovery, the identity endpoint URL should look like this:<br><br><a class="moz-txt-link-freetext" href="https://hostname:35357/" target="_blank">https://hostname:35357/</a><br><br>
And then they can navigate down to <br><br><a class="moz-txt-link-freetext" href="https://hostname:35357/v3" target="_blank">https://hostname:35357/v3</a><br><br>
Via discovery. So, what I am proposing for Keystone (here:
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/62801/" target="_blank">https://review.openstack.org/#/c/62801/</a>) is that we do this<br><br>
If the Catalog endpoint looks like this:
<a class="moz-txt-link-freetext" href="https://hostname:35357/v2.0/" target="_blank">https://hostname:35357/v2.0/</a> chop off /v2.0 and call on it for
discover.<br><br>
Now, the code In that link *will* work the same on a
<a class="moz-txt-link-freetext" href="https://hostname:35357/v3/" target="_blank">https://hostname:35357/v3/</a> due to the regex (copied from termie who
recognized this problem long ago) and that may scare you into
saying "won't we have this problem in the future?"<br><br>
Maybe, if we are stupid. We've been stupid before, so I can't
promise anything. However, much more important is that, as the
tools for deployment get smarter, they stop putting out Service
catalogs with versions in the URLS. They would have to deliberately
replace an explicit /v3 into the url in place of the V2.0 Then,
yes, the hack would still silently work.<br><br>
But without the hack, if they only check against the the V3 API, it
will still work, too. Broken again, and we are back here....this
really is something that requires education across the deployers.<br></blockquote><div><br></div><div>So we've been around this problem a few times and i've tried every other solution i can think of and it never quite works so i pretty much agree.<br></div><div><br></div><div>What i'd like to know and see really well defined is how we get out of this position once we're in it. Yes we can educate deployers and such but at some point we have the situation where our clients are going to be able to accept an endpoint from the service catalog that is wrong and we'll need to deprecate that behaviour. The ripping a band-aid metaphor seems appropriate here, When do we get to deprecate this and are we just delaying (possibly increasing as now we have to deprecate changes on the server and on the client) that pain that we could just declare a one-off hit for? <br></div><div><br>(Note that i am well aware that even our own clients cannot handle this currently, things would still need to be fixed)<br></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><blockquote cite="mid:CAOJFoEtyGs8wP3XJ1ooyqgy_AwA_csF5wHCVD=aX_JjXefvOLA@mail.gmail.com"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Problem 1: API version discovery is not universally
considered to be part of the API and therefore is not
defined by most services beyond them responding to a '/'
request with a 300 response and a list of versions. No two
of these responses look alike except where the source was
copied from an existing service.</div><div><br></div><div>Problem 2: Identity is unique in that it is handed a
deployment-defined URL to authenticate and get endpoints
for all other services. Most of these auth URLs have a
version hard-coded in them because the client didn't do
version discovery or negotiation until recently. This is
what we're talking about here, how to remove the version
from this URL and not break old clients. We can't. Not
without doing nasty things like detecting an old client
and compensating for it server-side. So we have to work
out a way for new clients to do discovery even when handed
a URL that has a version in it.</div><div><br></div><div>I've tested a couple of more generalized approaches,
and the best solution I have found so far is to simply
special-case the known legacy behaviour then drop in to
the general discovery process. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
I also wonder if this is an issue with version discovery
implementation.<br>
It seems like if we think this is going to be affecting
multiple<br>
services before doing an odd hack for keystone, we should
actually<br>
figure out a pattern that works for all services, and
figure out why<br>
this has only just become an issue. Most of the other
services have done<br></blockquote><div><br></div><div>The services that traditionally embed a version inside
the URL followed by a tenant ID or something get even
deeper into parsing the URL to hack the version.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
dual APIs at some point over the last 2 years, and this
didn't seem to<br>
trip them up too badly. What happened differently in
keystone that made<br>
this an issue? And what can be learned about how we
structure APIs going<br>
forward.</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">I think the difference is this is the
first API we have actually tried to deprecate and we don't
have the option to hide it in an updated SC endpoint. The
service catalog has hidden a lot of this pain for other
services because the clients generally can use whatever
endpoint the SC gives it.</div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div>a) Version discovery needs to be rationalized across the
services. We've talked about this at summits before, and
proposals have been written. And here we are. We'll do it
again in Atlanta, hopefully for the last time.</div><div><br></div><div>b) Define a common structured endpoint and let the client
assemble the components into the final URL. If the service
catalog had a base URL for compute, and a list of versions,
and the additional bits to be appended the client could make
an intelligent choice and assemble the endpoint. It isn't
like the client doesn't already have to know how the REST
URLs are constructed.</div><div><br></div><div>b-alt) Stop putting things like tenant IDs in the SC.
This has the same issue as the auth URL in how to do this
without instantly breaking the existing clients.</div><div><br></div><div>dt</div><div><br></div>
-- <br><br>
Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div></div><br><br><pre>_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></pre></blockquote><br><br>_______________________________________________<br>OpenStack-dev mailing list<br>OpenStack-dev@lists.openstack.org<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote><div><br></div></div></body></html>