We had a few instances where the title level used for calls in the
api-ref was wrong, resulting in the api call being hidden inside the
details of another title level.
This fixes title levels to be consistent and adds a missing inclusion to
the v2 index.
Closes-bug: #1787203
Change-Id: I602250117dbf52f9e031e945040b45f089d8602e
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
There are some small mistakes in the api-v2 doc,
please see this bug description:1733148
Closes-Bug:#1733148
Change-Id: I3726159a23625a33415f23b971d6e6f47bd77846
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
Modifies heading levels in .inc files to allow nested display in
table of contents. Table of contents depth has been changed to allow
this.
Change-Id: I3d8c9cf38a12272f0d32d3aa183d741277767535
Because of the underlying SQLAlchemy qos-specs functionality, which is
the only in-tree DB implementation, requiring context.is_admin to be
True, it's not technically correct to say "Administrators only,
depending on policy settings." Even if the associated
volume_extension:qos_specs_manage policy doesn't require an
"administrator", the @requires_admin_context decorator on the
underlying functionality definitely will.
ERROR: User does not have admin privileges (HTTP 403)
Change-Id: I0bc6a59c612b6c4ff7dcaff36dad712d8e3e03c2
Partial-Bug: #1621715
