6b11d276d1
Many changes to the Cinder REST API require changes to the consumers of the API. For example, If we need to add a required parameter to a method that is called by Nova, we'd need both the Nova calling code and the cinderclient that Nova uses to change. But newer Cinder versions with the change must work with older Nova versions, and there is no mechanism for this at the moment. Adding microversions will solve this problem. With microversions, the highest supported version will be negotiated by a field in the HTTP header that is sent to the Cinder API. In the case where the field 'versions' is not sent (i.e. clients and scripts that pre-date this change), then the lowest supported version would be used. In order to ensure that the API consumer is explicitly asking for a microversioned API, a new endpoint v3 is added, which is identical to API version v2. This means that our new Cinder API v3 would be the default, and consumers of the API that wished to use a newer version could do so by using that endpoint and a microversion in the HTTP header. New tests for microversioned API features on endpoint /v3 should be added to cinder/tests/unit/api/v3/ directory. Existing functionality will be tested via the .../v2/ unit tests. DocImpact APIImpact Implements: https://blueprints.launchpad.net/cinder/+spec/cinder-api-microversions Change-Id: I48cdbbc900c2805e59ee9aebc3b1c64aed3212ae
1.7 KiB
1.7 KiB
Developer Guide
In this section you will find information on Cinder's lower level programming APIs.
Programming HowTos and Tutorials
development.environment api_microversion_dev api_microversion_history unit_tests addmethod.openstackapi drivers gmr replication migration api.apache
Background Concepts for Cinder
architecture threading i18n rpc
Other Resources
launchpad gerrit jenkins releasenotes
API Reference
../api/autoindex
Module Reference
services database volume auth api scheduler fakes cinder
Indices and tables
genindexmodindexsearch