Access rules rules allow API will now take three additional
parameters:
- lock_visibility: when True, only services, administrators and
the same user will be able to see the content of ``access_to`` and
access_key.
- lock_deletion: when True, the access rule will be locked for
deletion. Only services, administrators or the user that placed
the lock will be able to drop the access rule.
- lock_reason: a reason for the lock. This parameter should only
be provided in the presence of at least one of the former
parameters.
In order to delete an access rule that is currently locked, the
requester will need to specify ``unrestrict=True`` in the request.
In case a service placed the restrictions, only the own service or
the system administrator will be able to release it.
This change also implements filters to the access list API. It is
now possible to filter access rules based on `access_to`,
`access_type`, `access_level` and `access_key`.
DocImpact
Change-Id: Iea422c9d6bc99a81cd88c5f4b7055d6a1cf97fdc
openstackdocstheme's custom styling doesn't display (h1)
headings in the body of the API ref. To work-around this
problem, demote the section headers and increase
the display level of the toctree.
Change-Id: I18b6ab44b62c4f17d854e5d32b4aef546992c79a
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
The key for access rule metadata in the API
request or response is just "metadata".
The "access_key" in /share-access-rules
endpoint responses doesn't need to specify
a min-version since its present in all API
versions that the endpoint itself is supported
with.
TrivialFix
Change-Id: I66ac3804f22d70ad673eb7185e5e7eb08843c811
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
As of API version 2.60, a project_id is no
longer needed in the API URLs.
Fix the docs to indicate that.
Also fix up a few quota parameters that use
project_id in a different place in the API path.
Change-Id: I24b32c8521805a7d67d512d36d644c0f07c532ea
Implements: bp remove-project-id-from-urls
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
Many APIs present information when the resource
in question was 'created_at' and 'updated_at'.
Having common parameters is easier to maintain in
the documentation since the description is the same
across the board.
Change-Id: Ia5d4ac399fe0d7983c61f5c5e0245d0987e97d6a
Partial-Bug: #1760644
Nowadays "project" and "project_id" are used instead of "tenant" in
the OpenStack world. See [1] and [2].
- Replace "tenant_id" in the API paths to "project_id"
- For most manila resources, the "project_id" in an API response body
refers to the project that owns the resource. So, create a unified
parameter and share that across the APIs.
- Fix path variable names, and their order
- Fix usage of "UUID" to refer to project and user IDs
- Fix query parameters
[1] https://docs.openstack.org/operations-guide/ops-projects-users.html
[2] https://developer.openstack.org/api-ref/identity/v3/index.html#projects
Partial-Bug: #1760644
Co-Authored-By: Goutham Pacha Ravi <gouthampravi@gmail.com>
Change-Id: I64e4ef8ad258d07c7d80d11a4d015c4b82156722
- Call out the maximum API version in Stein (2.49)
- Add parameter 'cast_rules_to_readonly' to share instance API ref
- Remove parameters 'export_location' and 'export_locations' from
share instance API ref.
- Add "min_version" and "max_version" annotations on parameters
where missing.
- Add "versionadded" annotation to APIs
- Add "DEPRECATED" annotation to deprecated APIs along with
a warning message.
Identical changes to the manage/unmanage APIs are handled
in https://review.openstack.org/#/c/647973/
Partial-Bug: #1760644
Change-Id: I5342cc26d1cbeea8ca3d55868e0f69d525333421
silvacarloss