Open Stack

On Sun, Feb 21, 2016 at 07:59:17PM +0200, Duncan Thomas wrote:
> 
> So we can't get users to change endpoints, or write our libraries to have
> sensible defaults, but we're somehow going to magically get consumers to do
> the much harder job of doing version probes in their code/libraries so that
> they don't get surprised by unexpected results? This seems to be entirely
> nuts. If 'they' can't change endpoints (and we can't make the libraries we
> write just do the right thing without needing to change endpoints) then how
> are 'they' expected to do the probing magic that will be required at some
> unpredictable poin tin the future, but which you'll get away without until
> then?
> 
> This would also make us inconsistent with the other projects that have
> implemented microversions - so we're changing a known working pattern, to
> try to avoid the problem of a user having to get their settings right if
> they want new functionality, and hoping this doesn't introduce entirely
> predictable and foreseeable bugs in the future that can't actually be fixed
> except by checking/changing every client library out there? There's no way
> that's a sensible API design.
> 
> 
> --
> Duncan Thomas

I've spent the weekend thoroughly convincing myself one way or the
other. The reality is, either one can _work_.

I've asked Scott to proceed with the /v3 endpoint though. Ultimately,
that is the safest route we can take to protect end users from
accidentally doing something bad.

A key thing here is that /v2 is not going away. So to an end user that
doesn't know or doesn't care, things will just keep on working the way
it has always worked and they don't need to worry.

As far as the argument that some folks are still using /v1 - from my
perspective they will need to migrate any way. So whether that is going
to /v2 or /v3, it really won't make much of a difference there.

Sean (smcginnis)

> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev