Add device identifier to replication device

One thing that may be needed by some back ends
that are implementing replication is some sort
of back end device identifier.

For managed back ends this shouldn't be an issue
but for unmanaged, it's handy to have some sort
of identifier string.

This patch just adds that to the response examples
in the volume.manager code as well as adds an update
to the dev docs to point it out.

Change-Id: Ic113d905e65c756439425b03035179e65ce0b39e
This commit is contained in:
John Griffith 2015-10-07 16:49:36 -06:00
parent 71355fdbad
commit bb59afc5ab
2 changed files with 14 additions and 6 deletions

View File

@ -3246,16 +3246,22 @@ class VolumeManager(manager.SchedulerDependentManager):
Example response for replicating to a managed backend:
{'volume_id': volume['id'],
'targets':[{'managed_host': 'backend_name'}...]
'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':[{'san_ip': '1.1.1.1',
'san_login': 'admin'},
....]}
{'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.
"""
try:

View File

@ -69,8 +69,10 @@ a backend_name, it takes the vendor unique config options::
volume_driver=xxxx
volume_backend_name=foo
managed_replication_target=False
replication_devices={'key1'='val1' 'key2'='val2' ...},
{'key7'='val7'....},...
replication_devices={'remote_device_id'='vendor-id-of-remote-backend',
'key1'='val1' 'key2'='val2' ...},
{'remote_device_id'='vendor-id-of-remote-backend',
'key7'='val7'....},...
Note the key/value entries can be whatever the device requires, we treat the actual
variable in the config parser as a comma delimited list, the {} and = notations are