[openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions
zigo at debian.org
Mon Feb 22 04:40:48 UTC 2016
On 02/18/2016 11:38 PM, D'Angelo, Scott wrote:
> Cinder team is proposing to add support for API microversions . It came up at our mid-cycle that we should add a new /v3 endpoint . Discussions on IRC have raised questions about this 
> Please weigh in on the design decision to add a new /v3 endpoint for Cinder for clients to use when they wish to have api-microversions.
> PRO add new /v3 endpoint: A client should not ask for new-behaviour against old /v2 endpoint, because that might hit an old pre-microversion (i.e. Liberty) server, and that server might carry on with old behaviour. The client would not know this without checking, and so strange things happen silently.
> It is possible for client to check the response from the server, but his requires an extra round trip.
> It is possible to implement some type of caching of supported (micro-)version, but not all clients will do this.
> Basic argument is that continuing to use /v2 endpoint either requires an extra trip for each request (absent caching) meaning performance slow-down, or possibility of unnoticed errors.
> CON add new endpoint:
> Downstream cost of changing endpoints is large. It took ~3 years to move from /v1 -> /v2 and we will have to support the deprecated /v2 endpoint forever.
> If we add microversions with /v2 endpoint, old scripts will keep working on /v2 and they will continue to work.
> We would assume that people who choose to use microversions will check that the server supports it.
I'd vote for the extra round trip and implementation of caching whenever
possible. Using another endpoint is really annoying, I already have
specific stuff for cinder to setup both v1 and v2 endpoint, as v2
doesn't fully implements what's in v1. BTW, where are we with this? Can
I fully get rid of the v1 endpoint, or will I still experience some
Thomas Goirand (zigo)
More information about the OpenStack-dev