We have to support old clients.
Old clients expect that the URL that comes back for the service catalog
has the version in it.
Old clients don't do version negotiation.
Thus, we need an approach to not-break old clients while we politely
encourage the rest of the world to move to later APIs.
I know Keystone has this problem. I've heard that some of the other
services do as well. Here is what I propose. It is ugly, but it is a
transition plan, and can be disabled once the old clients are deprecated:
HACK: In a new client, look at the URL. If it ends with /v2.0, chop it
off and us the substring up to that point.
Now, at this point you are probably going: That is ugly, is it really
necessary? Can't we do something more correct?
No. I mean, we are already doing something more correct in that the
later versions of the Keystone client already support version
discovery. The problem is that older clients don't.
Alternatives:
1. Just chop the url. Now only clients smart enough to do negotiation
work. Older clients no longer work. Suck it up.
2. Put multiple endpoints in the service catalog. Ugh. Now we've just
doubled the size of the service catalog, and we need new logic to get
the identityv3 endpoints, cuz we need to leave "identity" endpoints for
existing clients.
3. Do some sort of magic on the server side to figure out the right URL
to respond to the client request. This kind of magic was banned under
the wizarding convention of '89.
Can we accept that this is necessary, and vow to never let this happen
again by removing the versions from the URLs after the current set of
clients are deprecated?
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
