In "List all hosts for a project", service-status should take
the values of ['available', 'unavailable'], (service-state takes
the value of ['enabled', 'disabled']), and because os-services API
uses service_status which requires returning `enabled` and `disabled`,
we need add a new parameter host_service_status for os-hosts API.
https://docs.openstack.org/api-ref/block-storage/v3/index.html#list-all-hosts-for-a-project
partially-implements: blueprint volume-response-schema-validation
Change-Id: Idde4a63f00862599a13bcfcdadc1d4459f27d3a4
Using the wrong character resulted in the wrong title level
being used for the response codes, which in turn caused the
"detail" show/hide toggle to not be able to hide all of the
per-endpoint details. This corrects these to be at the correct
level.
Also ran into issues after changing them where sphinx was not
happy with the random title levels. This appears to be due to
the order processed and whether not earlier included files had
all subsequent levels. Adding an additional title in our first
included file resolved that problem.
Change-Id: I19405778980310f2d6d06eb7b23102f74a3d6e03
Closes-bug: #1755566
Rather than our freeform way of listing response codes in our
api-ref, we should be using the os-api-ref extension option to
get nicely formatted response code listings.
https://docs.openstack.org/os-api-ref/latest/usage.html#rest-status-code
Change-Id: Iee21f54fe7cf0ea28258966e2d0f8fa2849c83f2
We had a mix of formatting for our API response codes. This
makes it so all have a leading space, no trailing comma, and
no empty Error response labels.
This also addresses a formatting issue with due to the spacing
between the Normal and Error lines that was causing the two to
run together in the formatted HTML, making it harder to read.
Change-Id: Ic411ee9f671c48ce60bda21984dafe55135685ba
Getting all hosts returns every Cinder service host, regardless
of which service is running on the host. But getting a specific
host will fail if you try it for a host not running cinder-volume.
This looks to be the behavior from the beginning, but there was
nothing denoting this, causing errors and confusion for code that
thought it could get a host from the list, then get detailed info
about that host. The details return volume and snapshot counts,
so it really only makes sense for cinder-volume, so the code ends
up returning a 404 for anything else.
This API design seems a little disjointed, but since this is how
it appears to have always been, just make sure the api docs have
the right details for potential API consumers to know what to
expect.
Change-Id: If53279cfcbbde1297bb2e55e17d17b473e7d0d6e
Closes-bug: #1691144