As discussed at the newton midcycle and in the dev
mailing list:
http://lists.openstack.org/pipermail/openstack-dev/2016-July/099860.html
We should add a Tempest test for any microversion that
changes the response schema so we have coverage in Tempest
and also so we don't have to fill large gaps in coverage
in Tempest when adding other unrelated tests.
Change-Id: Ie7cfe7ee857caf630d4380cf673ae208842fbc00
In this change the new OpenStack-API-Version headers is allowed,
but not required, for requesting a microversion.
Both headers are accepted in the request and both headers are sent in
the response (both the header and its value, and the addition to the Vary
header).
Many tests which explicitly use a microversion header have been
updated to use both. This change is not 100% as most of the tests
are testing the handling of the value of the header, not which
header is involved.
Partially-Implements: blueprint modern-microversions
Change-Id: I68da13b5ba0c2f3357523e765a5b9db81899daf1
There was some confusion/debate in reviewing
I5fa1fdba56803b2ef63b1efaaeeced6ceb7779d9 and whether or
not it required a microversion to change the response code.
This was a pretty common sense scenario where 415 was a
more appropriate error code for 400 and is a better client
experience when hitting that error.
This change updates the potentially confusing part of the
devref about this and adds a note to ask the Nova API
subteam when in doubt about whether or not a microversion
is needed for changing error codes.
Change-Id: I8a2836076b7fadc697bdc013578c3d777d02a833
Related-Bug: #1567977
According to the Cinder devref:
https://github.com/openstack/cinder/blob/master/doc/source/devref/api_microversion_dev.rst)
you should be able to use the following pattern:
def index(self, req):
<common code>
req_version = req.api_version_request
if req_version.matches("3.1", "3.5"):
....stuff....
elif req_version.matches("3.6", "3.10"):
....other stuff....
elif req_version > api_version_request.APIVersionRequest("3.10"):
....more stuff.....
<common code>
However, the api_version_request.matches() function will not accept a
string, it requires an api_version_request object.
This changes the doc to implement an api_version_request object to use
this pattern.
Closes-Bug: #1550337
Change-Id: I14a943b21e9e98dd848c0c292ca1a1ae941cb98b
current API microversion document mentioned no need to bump
version if we change from 500 error to 4xx error,
in this case, 503 (service unavailable) also can't be handled
by client side so it should be fine to change without bump.
This patch comes from I80a07222f44017448d1877d6b821eebe462d9fec
discussion.
Change-Id: I2500698b821797568e2564176e87938f2b0f9ae5
Based on https://review.openstack.org/#/c/214691/
Some concern raised about remove a header may need
microversion bump, update devref to indicate that
it sould be ok to update without microversion usage.
Co-Authored-By: Alexis Lee <lxsli@hpe.com>
Change-Id: I0b9e6e384b54ae8bfc7896f0135cd443ccfe2b1e
Python-novaclient need to be updated to address new microversion
API change , so add some suggestions in the doc.
Change-Id: Ibb2d137a6a16badea7c2619d210317b7a098ec4e
per https://review.openstack.org/#/c/164229
suggested on the spec, we should not suggest private method
decoration on microversion, so this update the doc to sync it
Change-Id: Ie937173a4d1542eb1c551795ca371ebce69c7078
no need to update microversion if only the error messages
are updated. e.g changing from 'Flavor name in bad format'
to 'name not found, type: Flavor' should not
need microversion if the error code keeps same.
Change-Id: I1ea66aedbc0a086338066d2757022ae3a9932015
Related-Bug: 1431932
404 error code is always one of the return code when url or
resource does not exist, so 404 is an available status code for all the
Nova API. Then no microversion bump required for fixing 500 to 404
.
Change-Id: I4b1703e82cd89192b2ba4ce2603741e33dd26586
compability -> compatibility
acknowledgement -> acknowledgment
Plus a small fix for config's note.
Change-Id: I0a02c5ac034470179c90af71748eb980fe8f7495
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
As the API validation code always return 400 when request with
invalid json body, so 400 is an available status code for all the
Nova API. Then no microversion bump required for fixing 500 to 400.
Change-Id: I0454e95cd0655c910fad8b39ead2b5edab216b68
Related-Bug: 1471239
Change Ia782ab9d9a31d37854606f7be82582de6d7bc374 returns a 403 rather
than a 500 for OverQuota and adds that to the list of expected errors in
the v2.1 case.
There is no microversion change required since the 403 case is implied
given keystone authentication can fail with a 403 on any API.
This change updates the docs to mention the exceptional case for 403.
Related-Bug: #1444559
Change-Id: I7ea8c5c50d4eac53837f5f76e09277ac185288a9
We shouldn't require a microversion bump for translating a 500 error to
some 400-level error code since 500s should not be part of the API
contract and clients shouldn't expect them for cases that the client can
change, i.e. don't ask for things that don't exist, don't ask to do
things that raise quote and you're already maxed out, etc.
There was some confusion in the doc about the statement that a
microversion is needed when changing from a 501 to a 400, but that's a
different case (going from something not being implemented to it
suddenly being implemented - that's a case where the client should
opt-in and a microversion bump is required).
Not returning 500s is just fixing bugs and shouldn't require a
microversion, the docs even already say that in the first footnote -
this just adds notes to clarify.
Also fixes the links to the [1] footnote.
Change-Id: I4526a72458a23662bd8aaa7f89be32844a511929
The "group" tag on nodes can be used to create vertical alignment, all
nodes in a group which are connected will end up in one column. This
makes reading the flow chart a bit easier.
Add a " " before the "no" edges otherwise they are left justified
completely to the vertical edge, and make it kind of gorpy to read.
Change-Id: Ife11e905ea6fdd97e1459fbbc001324eb946f9e4
This documents what we consider the contract in Nova, and what kinds
of things trigger needing a new microversion. It also includes a flow
chart for folks that are more visually inclined.
Change-Id: I6dbadbf7cb23e27b96a0ae191419c8adf6ffe006
Make the API microversion history more accessible by adding it to nova's
doc landing page.
Making sure it is easy to discover what the difference between each
microversion is fundamental piece of the microversion puzzle, so lets
not require end users to have to look through git.
rename api_microversions.rst to api_microversion_dev.rst to clarify that
it is about development and versus history.
Change-Id: I270944bf9739b113a43b932948fdbf83e449603b
Matt Riedemann