Open Stack

On 10/19/2016 04:22 PM, Matt Riedemann wrote:
> I personally thought long-term we wanted unversioned endpoints in the
> service catalog, and if you want to do version discovery, you do a GET
> on a particular service's endpoint URL in the service catalog, and that
> returns the list of available API versions for that service along with a
> status value (CURRENT, SUPPORTED, DEPRECATED) and any microversion
> ranges within those.
>
> I know we have 3 versions of keystone in the service catalog, which I
> find pretty nasty personally, plus the fact that a lot of the client
> code we have has had to burn 'volumev2' in as a default endpoint_type to
> use cinder. IMO the service catalog should just have a 'volume' endpoint
> and if I want to know the supported versions (v1, v2 and/or v3), I do a
> GET on the publicURL for the volume endpoint from the service catalog.

At 5 services, maybe. But at 50+ services (and growing) I think that the 
idea of get an endpoint, then have custom parsing code for every service 
because their version documents are different, is a really bad UX.

The reason we have volume, volumev2, and volumev3 is that no one 
actually wants the unversioned volume endpoint. You can't do anything 
with it. Everyone wants the actual endpoint that has resources.

We can solve this for all consumers by adding additional version field 
to the catalog. This was the direction we were headed last spring before 
the api-ref work took over.

I think Brian's initial complaints (which are very valid) here really 
point to the fact that punting on that puts SDK and client authors in a 
place where they are going to end up writing a ton of heuristic code to 
guess url structure. Which would be sad for all of us. :(

	-Sean

-- 
Sean Dague
http://dague.net