openstack/cinder
Code Issues Proposed changes

Merge "Update list_replication_targets"

Browse Source
This commit is contained in:
Jenkins 2015-11-26 16:08:36 +00:00 committed by Gerrit Code Review
commit 084b3af44a
3 changed files with 25 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
cinder/volume/driver.py
View File

@ -215,7 +215,7 @@ volume_opts = [
"times in a single config section to specify multiple "
"replication target devices. Each entry takes the "
"standard dict config form: replication_device = "
"device_target_id:<required>,"
"target_device_id:<required>,"
"managed_backend_name:<host@backend_name>,"
"key1:value1,key2:value2..."),
cfg.BoolOpt('image_upload_use_cinder_backend',

28
cinder/volume/manager.py
View File

@ -3323,28 +3323,22 @@ class VolumeManager(manager.SchedulerDependentManager):
This method is used to query a backend to get the current
replication config info for the specified volume.
In the case of a volume that isn't being replicated,
the driver should return an empty list.
There is one required field for configuration of
replication, (target_device_id). As such we
use that for the response in list_replication_targets.
Example response for replicating to a managed backend:
Internal methods can be added to extract additional
details if needed, but the only detail that should be
exposed to an end user is the identifier. In the case
of an Admin, (s)he can always cross check the cinder.conf
file that they have configured for additional info.
Example response:
{'volume_id': volume['id'],
'targets':[{'remote_device_id': 'vendor-id-for-target-device',
'managed_host': 'backend_name'}...]
Example response for replicating to an unmanaged backend:
{'volume_id': volume['id'], 'targets':[
{'remote_device_id': 'vendor-id-for-target-device',
'san_ip': '1.1.1.1',
'san_login': 'admin'},
....]}
NOTE: It's the responsibility of the driver to mask out any
passwords or sensitive information.
`remote_device_id` is required and is used for drivers to identify
the devices they have in use.
'targets':[<target-device-id>,...]'
"""
# NOTE(hemna) We intentionally don't enforce the driver being

26
doc/source/devref/replication.rst
View File

@ -31,9 +31,12 @@ like to configure.
There are two standardized keys in the config
entry, all others are vendor-unique:
* device_target_id:<vendor-identifier-for-rep-target>
* target_device_id:<vendor-identifier-for-rep-target>
* managed_backend_name:<cinder-backend-host-entry>,"
target_device_id is REQUIRED in all configurations
An example config entry for a managed replication device
would look like this::
@ -209,17 +212,14 @@ act as a toggle, allowing to switch back and forth betweeen primary and secondar
**list_replication_targets**
Used by the admin to query a volume for a list of configured replication targets
The expected return for this call is expected to mimic the form used in the config file.
Used by the admin to query a volume for a list of configured replication targets.
For a volume replicating to managed replication targets::
{'volume_id': volume['id'], 'targets':[{'type': 'managed',
'backend_name': 'backend_name'}...]
For a volume replicating to external/unmanaged targets::
{'volume_id': volume['id'], 'targets':[{'type': 'unmanaged',
'san_ip': '127.0.0.1',
'san_login': 'admin'...}...]
The expected response is simply the single required field in replication-device
configuration. It's possible that in the future we may want to add a show
command that provides all the various details about a target replication
device. This would be of the form:
`show_replication_target <target_device_id>`
Example response:
{'volume_id': volume['id'],
'targets':[<target-device-id>,...]'