Open Stack

On Wed, 19 Oct 2016, Sean Dague wrote:

> 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.

That's right, they do want the endpoint that has the resources, but
do they care about asking for a version? I'm not sure. I think they
just want the thing that's going to work and the version is
superfluous.

> 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'd rather not see versions in the service catalog as a reified entity
because it increases the surface area of an endpoint request. I don't
want to have think which version I want. Or if I do, I want it to be
built into the service type. We want the service type to be the
entrypoint for endpoints...

In any case, just for reference, both the arch-wg and the api-wg
have expressed a lot of concern about and interest in the service
catalog (and the service authority idea that was bouncing around for
a while too). So I agree with everyone else who is saying "yeah,
it's time to make this better."

There are a lot of issues:

* how to deal with versions
* auth handling at the top-level endpoint
* service type value consistency amongst clouds
* public, internal, admin, whatever endpoints (can we make it so
   there is one and only one‽)
* dynamic v static service catalogs in the face of different
   contexts
* whatever else I'm forgetting right now because the coffee is weak
   but I'm sure someone else remembers

-- 
Chris Dent               ┬─┬ノ( º _ ºノ)        https://anticdent.org/
freenode: cdent                                         tw: @anticdent