[openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions
sean at dague.net
Mon Feb 22 11:48:40 UTC 2016
On 02/21/2016 12:59 PM, Duncan Thomas wrote:
> On 21 February 2016 at 19:34, Jay S. Bryant
> <jsbryant at electronicjungle.net <mailto:jsbryant at electronicjungle.net>>
> Spent some time talking to Sean about this on Friday afternoon and
> bounced back and forth between the two options. At first, /v3 made
> the most sense to me ... at least it did at the meetup. With people
> like Sean Dague and Morgan Fainberg weighing in with concerns, it
> seems like we should reconsider. Duncan, your comment here about
> customers moving when they are ready is somewhat correct. That,
> however, I am concerned is a a small subset of the users. I think
> many users want to move but don't know any better. That was what we
> encountered with our consumers. They didn't understand that they
> needed to update the endpoint and couldn't figure out why their new
> functions weren't working.
> So, I am leaning towards going with the /v2 endpoint and making sure
> that the clients we can control are set up properly and we put
> safety checks in the server end. I think that may be the safest way
> to go.
> 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.
Nova did a seperate endpoint mostly because we actually had an entirely
duplicate wsgi stack (which was going to be v3). We needed 2 endpoints
to make sure that the base microversion was indistinguishable.
Manilla did a dedicated endpoint for philosophical reasons.
Ironic just extended the /v1 in place.
More information about the OpenStack-dev