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