cinder/api-ref/source/v3/capabilities-v3.inc
Sean McGinnis fffdac20c2 api-ref: Make v3 enclosing objects consistent
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
2017-09-01 09:54:34 -05:00

49 lines
1.1 KiB
ReStructuredText

.. -*- rst -*-
Capabilities for storage back ends (capabilities)
=================================================
Shows capabilities for a storage back end.
Show all back-end capabilities
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. rest_method:: GET /v3/{project_id}/capabilities/{hostname}
Shows capabilities for a storage back end on the host.
The ``hostname`` takes the form of ``hostname@volume_backend_name``.
Normal response codes: 200
Request
-------
.. rest_parameters:: parameters.yaml
- project_id: project_id_path
- hostname: hostname
Response Parameters
-------------------
.. rest_parameters:: parameters.yaml
- pool_name: pool_name
- description: description
- volume_backend_name: volume_backend_name
- namespace: namespace
- visibility: visibility
- driver_version: driver_version
- vendor_name: vendor_name
- properties: properties
- storage_protocol: storage_protocol
- replication_targets: replication_targets
- display_name: display_name
Response Example
----------------
.. literalinclude:: ./samples/backend-capabilities-response.json
:language: javascript