The various index APIs (e.g. 'GET /volumes') support two forms of sort
parameter: the legacy 'sort_key'/'sort_dir' parameters and the combined
'sort' parameter. We were documenting different parameters in different
APIs despite the fact all APIs support all parameters.
In a similar vein, the various index APIs support the same three
pagination parameters: 'offset', 'limit', and 'marker'. Once again, we
were documenting these inconsistently.
Correct both issues.
Change-Id: Ia3300a8852825f7da830f7b1ed37b27625e267e9
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Fix a typo and update the headings currently missing the resource
name (may seem redundant, but it's important because some have '_'
and some have '-' in the name).
Change-Id: I47bf40759b9f298dbdc2fcc59e0617d8b5f3fc0b
The parameters with name like example_1, example_2 ... etc. cause
confusion while updating the api-ref docs like the examples below:
https://review.openstack.org/#/c/609639/https://review.openstack.org/#/c/609611/
This patch does the following changes :
1) Replace numbering in the parameter with relevant names
2) Clean up unused parameters
Change-Id: I35b343bf068281d729576e5ecc209bda60c28680
I512bfc97a1c3d4a508daf580d99fefe2a9ae4e13 tries to add response
schema validation for messages interfaces, and there are some
inconsistencies in api ref:
1. delete message success code is 204, not 202
2. id is of the format uuid, which means string, not integer.
Change-Id: I13280bf158f541ed0514930274df8c03a0f81c4c
The description for the messages API was very terse. This adds some more
details to provide some description of what the API is used for.
Change-Id: If15400e9a538bf533e93f9693b6eddeb114fa7e5
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
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
Some request details provided information about the other
JSON value while others didn't. To make things consistent
and to make sure API consumers understand how the requests
need to be structured, this adds missing instances. It also
reorders some parameter lists to be a little more logical,
so even though we can't show the nested nature of some of
these, it at least doesn't show inner values before outer
ones.
This also corrects many errors seen while going through
the API ref. This is by no means exhaustive, and is already
somewhat out of the scope for this patch, so it is expected
that there are some (many) cases that are not addressed by
this patch. Those will be fixed with ongoing effort in
future patches.
Partial-bug: #1713517
Change-Id: I30964ba8d829778fd01174d639d44ba07e4b77a6
Now cinder will raise 400 if invalid filter
keys are specified, Update the corresponding
list APIs.
DocImpact
Depends-On: ff3d41b15abb2915de87830980147be51e5da971
Change-Id: I8419b374d7f743e7e9fc88e31c8c4f7d9470059b
