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 [1] https://etherpad.openstack.org/p/cinder-api-microversions [2] https://www.youtube.com/watch?v=tfEidbzPOCc around 1:20 [3] http://eavesdrop.openstack.org/irclogs/%23openstack-cinder/%23openstack-cinder.2016-02-18.log.html around 13:17 __________________________________________________________________________ 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
