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