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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
