Open Stack

On 02/18/2016 11:38 PM, D'Angelo, Scott wrote:
> Cinder team is proposing to add support for API microversions [1]. It came up at our mid-cycle that we should add a new /v3 endpoint [2]. Discussions on IRC have raised questions about this [3]
> 
> 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.
> 
> Scottda

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
Tempest failures?

Thomas Goirand (zigo)