Open Stack

On Tue, Feb 4, 2014 at 9:00 AM, Sean Dague <sean at 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.
>

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
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140204/441793dd/attachment.html>