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
Users of replicated shares expect to see primary
export locations when viewing information regarding
the share. Because we collate exports of all replicas
within the export locations APIs, it becomes hard for
users to discern which exports belong to the primary
share. For secondary replicas, users would also need
additional information (availability zone, state of the
replication) to work with.
Introduce micro-version 2.47 from which the export locations
API (GET /v2/{tenant_id}/shares/{share_id}/export_locations)
no longer provides export locations of non-active share
replicas. A new API has been introduced to provide export
location details for share replicas, both active and non-active.
(GET /v2/{tenant_id}/share-replicas/{share_replica_id}/export-locations)
The new API provides the replica's state and availability zone
in addition to the export location information.
APIImpact
Implements: bp export-locations-az
Change-Id: I0a1d9dd00b4c13ac01988e30ca2b7d7ce4a747d1