diff --git a/specs/mitaka/add_pagination_to_other_resources.rst b/specs/mitaka/add_pagination_to_other_resources.rst index caaed323..960b541d 100644 --- a/specs/mitaka/add_pagination_to_other_resources.rst +++ b/specs/mitaka/add_pagination_to_other_resources.rst @@ -52,8 +52,9 @@ None REST API impact --------------- -According the API-wg guideline about pagination, filter and sort[2]. -* GET /v2/{project_id}/{resource}?limit=xxx&marker=xxx&sort=xxx&{filter}=xxx +According the API-wg guideline about pagination, filter and sort[2]:: + + GET /v2/{project_id}/{resource}?limit=xxx&marker=xxx&sort=xxx&{filter}=xxx RESP BODY: {"resource_links": [{xxx}], "resource": [{xxx}, {xxx}, ..., {xxx}] } diff --git a/specs/mitaka/api-microversions.rst b/specs/mitaka/api-microversions.rst index 2e2c3407..45cdc6fb 100644 --- a/specs/mitaka/api-microversions.rst +++ b/specs/mitaka/api-microversions.rst @@ -118,7 +118,7 @@ A version response would look as follows for GET http://:8776 :: -{ + { "versions": [ { "id": "v2.0", @@ -177,7 +177,7 @@ A version response would look as follows for GET http://:8776 "version": "2.1" } ] -} + } This specifies the min and max version that the server can understand. min_version will start at 2.0 representing the v2.0 API. @@ -456,13 +456,13 @@ Primary assignee: Work Items ---------- -Port Manila code for api-microversions +* Port Manila code for api-microversions Status: Done (see https://review.openstack.org/#/c/224910/) -Add examples of increments and decorators (scottda) +* Add examples of increments and decorators (scottda) Status: Done (see https://github.com/scottdangelo/TestCinderAPImicroversions) -Implement changes for python-cinderclient (scottda) -test with python-cinderclient changes (scottda) -Cinder Doc changes (scottda) +* Implement changes for python-cinderclient (scottda) +* test with python-cinderclient changes (scottda) +* Cinder Doc changes (scottda) Dependencies @@ -497,4 +497,5 @@ References * Manila code for api-microversions: https://review.openstack.org/#/c/207228/8 * WIP implementation code: https://review.openstack.org/#/c/224910/ * Test Cases and code: https://github.com/scottdangelo/TestCinderAPImicroversions + .. _OpenStack API Change Guidelines: http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html diff --git a/specs/mitaka/assisted_snapshot_improvements.rst b/specs/mitaka/assisted_snapshot_improvements.rst index a22e29c5..a6f217cf 100644 --- a/specs/mitaka/assisted_snapshot_improvements.rst +++ b/specs/mitaka/assisted_snapshot_improvements.rst @@ -43,6 +43,7 @@ API<->Volume service interaction Establish a snapshot_admin_metadata table which is similar to the volume_admin_metadata table:: + id : Integer, primary key, key : string, value : string, @@ -63,6 +64,7 @@ call for each stage, rather than only a single delete_snapshot call. The driver will have a property indicating it supports assisted snapshots, which triggers use of the following methods in the manager instead of the manager calling the driver's create_snapshot:: + create_snapshot_assisted_begin(snapshot_ref) create_snapshot_assisted_complete(snapshot_ref) diff --git a/specs/mitaka/backup-snapshots.rst b/specs/mitaka/backup-snapshots.rst index 1e6e7644..bcbb2f60 100644 --- a/specs/mitaka/backup-snapshots.rst +++ b/specs/mitaka/backup-snapshots.rst @@ -47,6 +47,7 @@ Proposed change =============== In summary, the following changes will happen: + * A field "snapshot_id" will be added to the request body of the existing backup API. * A new column "snapshot_id" will be added to the backups table. @@ -231,6 +232,7 @@ Documentation Impact Documentation will be modified to describe how to use this feature. We will make sure both the existing use cases and the new use cases are clearly documented to avoid confusion. The following should be covered: + * Do a full backup of a volume with status being 'available' or 'in-use'. * Do an incremental backup of a volume with status being 'available' or 'in-use'. diff --git a/specs/mitaka/brocade-zone-driver-friendly-zone-names.rst b/specs/mitaka/brocade-zone-driver-friendly-zone-names.rst index 75eb69e7..57e6b0b3 100644 --- a/specs/mitaka/brocade-zone-driver-friendly-zone-names.rst +++ b/specs/mitaka/brocade-zone-driver-friendly-zone-names.rst @@ -66,9 +66,9 @@ is not documenting the ways the volume driver fetch the storage system value. It is up to the volume driver to implement a mechanism to retrieve the storage system value. -Connection Info samples: +Connection Info samples:: -{ + { 'driver_volume_type': 'fibre_channel' 'data': { **'storage_system': 'AMCE_Array',** @@ -78,9 +78,11 @@ Connection Info samples: 'target_wwn': '1234567890123', 'access_mode': 'rw' } -} -or -{ + } + +or:: + + { 'driver_volume_type': 'fibre_channel' 'data': { **'storage_system': 'AMCE_Array',** @@ -90,7 +92,7 @@ or 'target_wwn': ['1234567890123', '0987654321321'], 'access_mode': 'rw' } -} + } On attach/detach, Zone Manager will be initialized with **connection_info** which is provided by volume driver. Zone Manager in turn will extract the host @@ -186,11 +188,11 @@ Work Items - Enhance the zone manager to pass connection_info object to zone driver. - Implement Brocade Zone Driver to create zones as per new format -using the host name and storage system in the connector object. + using the host name and storage system in the connector object. - Implement Cisco Zone Driver to create zones as per new format using -the host name and storage system in the connector object. + the host name and storage system in the connector object. - Volume drivers are expected to add storage system information to -connector object. + connector object. - Unit test the zone driver and client code. diff --git a/specs/mitaka/brocade-zone-driver-virtualfabrics-support.rst b/specs/mitaka/brocade-zone-driver-virtualfabrics-support.rst index 98ac2248..ff20bfa6 100644 --- a/specs/mitaka/brocade-zone-driver-virtualfabrics-support.rst +++ b/specs/mitaka/brocade-zone-driver-virtualfabrics-support.rst @@ -73,27 +73,28 @@ service to traverse through the fabrics configured in cinder.conf to identify the targets connected to a host and returns a map of initiator and target port WWNs for each fabric. -Sample map object returned by the look up service: +Sample map object returned by the look up service:: - { - : { - 'initiator_port_wwn_list': - ('200000051e55a100', '200000051e55a121'..) - 'target_port_wwn_list': - ('100000051e55a100', '100000051e55a121'..) - } - : { - 'initiator_port_wwn_list': - ('300000051e55a100', '300000051e55a121'..) - 'target_port_wwn_list': - ('400000051e55a100', '400000051e55a121'..) - } - } + { + : { + 'initiator_port_wwn_list': + ('200000051e55a100', '200000051e55a121'..) + 'target_port_wwn_list': + ('100000051e55a100', '100000051e55a121'..) + } + : { + 'initiator_port_wwn_list': + ('300000051e55a100', '300000051e55a121'..) + 'target_port_wwn_list': + ('400000051e55a100', '400000051e55a121'..) + } + } The volume driver will process this information to extract initiator and target map for each fabric and builds a new initiator_target_map object. -Sample initiator_target_map object: +Sample initiator_target_map object:: + { 'host WWPN 1': ['target WWPN 1', 'target WWPN 2'] 'host WWPN 2': ['target WWPN 3', 'target WWPN 4'] diff --git a/specs/mitaka/capacity-headroom.rst b/specs/mitaka/capacity-headroom.rst index 28ffb05c..e40cb60a 100644 --- a/specs/mitaka/capacity-headroom.rst +++ b/specs/mitaka/capacity-headroom.rst @@ -74,12 +74,12 @@ New methods in HostState * get_capacity() - call get_pools() - - calculate the capacity info for pool and then sum for each - backend + - calculate the capacity info for pool and then sum for each backend Alternatives ------------ Another alternative could be: + * create a new data table which describe capacity info into database in scheduler. * provide a cinder api to retrieve the capacity info from database. diff --git a/specs/mitaka/cinder-api-atomic-status-change.rst b/specs/mitaka/cinder-api-atomic-status-change.rst index 0b36b868..4b05207a 100644 --- a/specs/mitaka/cinder-api-atomic-status-change.rst +++ b/specs/mitaka/cinder-api-atomic-status-change.rst @@ -104,7 +104,8 @@ checking the ``status`` of a volume and raise a message if it is not then raise a different exception or the same exception with a different message. -Skeleton of the procedure: +Skeleton of the procedure:: + result = resource.conditional_update(values, conditions) if not result: resource = db.get_resource(resource.id) @@ -124,7 +125,8 @@ call without having changed the DB, which is a problem. That is why we need a loop in the conditional update, to make sure we either succeed on the update or we raise the error regardless of racing conditions on the data. -Updated skeleton of the procedure: +Updated skeleton of the procedure:: + while not resource.conditional_update(values, conditions): resource = db.get_resource(resource.id) raise_right_validation_error(resource) diff --git a/specs/mitaka/support-volume-glance-metadata-query.rst b/specs/mitaka/support-volume-glance-metadata-query.rst index 9c98ad75..9dc7847d 100644 --- a/specs/mitaka/support-volume-glance-metadata-query.rst +++ b/specs/mitaka/support-volume-glance-metadata-query.rst @@ -34,7 +34,8 @@ Proposed change * Add DB query filter using volume_glance_metadata in api of sqlaclchemy. * User can use glance metadata to filter volume detail in cinder api. - The query url is like this: + The query url is like this:: + "volumes/detail?glance_metadata={"image_name":"xxx"}" Alternatives