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
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: Ibafafa2f9c3b301b5cdd9b1cb3b8b6d678faa731
Things like following is in api-ref, need to be correct.
1. use share_id and remove share_id_4
2. export_location_id_path param is required
3. security_service_id is required not optional
This patch is to fix these.
Change-Id: Ic811095b85a0460d3c6bedc9526d8ed64248de4c
Closes-bug: #1719543
The API Documentation team has requires [1] that
projects maintain their api-reference in-tree and
build it to the developer.openstack.org website.
This version of the API reference uses os-api-ref
and compiles API documentation close to that of
the OpenStack compute service (nova).
Co-Authored-By: Goutham Pacha Ravi <gouthamr@netapp.com>
[0] http://lists.openstack.org/pipermail/openstack-dev/2016-May/093765.html
Implements: bp move-manila-api-reference-in-tree
Change-Id: I67bb3354162d6e0e00fa2788edde864cc14920ee