On 02/04/2014 11:09 AM, Dean Troyer wrote:
On Tue, Feb 4, 2014 at 9:00 AM, Sean Dague <s...@dague.net
<mailto:s...@dague.net>> wrote:
Can you be more specific about what goes wrong here? I'm not entirely
sure I understand why an old client of arbitrary age needs to be
supported with new OpenStack. The contract is the API, not the client,
and an old client that doesn't do version discovery is just a buggy
client from what I'm concerned. Time to release a new version.
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:
https://hostname:35357/v2.0/
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:
https://hostname:35357/
And then they can navigate down to
https://hostname:35357/v3
Via discovery. So, what I am proposing for Keystone (here:
https://review.openstack.org/#/c/62801/) is that we do this
If the Catalog endpoint looks like this: https://hostname:35357/v2.0/
chop off /v2.0 and call on it for discover.
Now, the code In that link *will* work the same on a
https://hostname:35357/v3/ 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?"
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.
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.
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.
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.
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.
I also wonder if this is an issue with version discovery
implementation.
It seems like if we think this is going to be affecting multiple
services before doing an odd hack for keystone, we should actually
figure out a pattern that works for all services, and figure out why
this has only just become an issue. Most of the other services
have done
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.
dual APIs at some point over the last 2 years, and this didn't seem to
trip them up too badly. What happened differently in keystone that
made
this an issue? And what can be learned about how we structure APIs
going
forward.
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.
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.
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.
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.
dt
--
Dean Troyer
dtro...@gmail.com <mailto:dtro...@gmail.com>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
