Hi Bruce,
Bruce Montague bruce_monta...@symantec.com wrote on 02/23/2014 03:35:10
AM:
Hi, regarding the proposed Cinder volume replication patch,
https://review.openstack.org/#/c/64026 :
The replication driver methods are create_replica(), swap_replica(),
delete_replica(),
replication_status_check(), enable_replica(), and disable_replica().
What are the expected semantics of the enable and disable methods? In
enable_vol_replication() it looks like the intent is that replicas
are created by
create, than started by enable (and vice versa for disable/delete).
One of the challenges in the replication design was creating a driver API
that would work for all backends. One way of doing so was to allow the
driver to execute on both sides of the replication. So when creating a
replicated volume we have:
1. primary backend: create_volume
2. secondary backend: create_replica
3. primary backend: enable_replica
When deleting a replicated volume we have the opposite:
1. primary backend: disable_replica
2. secondary backend: delete_replica
3. primary backend: delete_volume
The goal here is to be flexible and allow all drivers to implement
replication. If you look at the patch for IBM Storwize/SVC replication (
https://review.openstack.org/#/c/70792/) you'll see two main replication
modes supported in replication.py. The first (starting on line 58) simply
requires making a copy of the volume in the proper pool, and so only
create_replica and delete_replica are implemented there. The second
method (starting on line 118) implements all of the functions:
create_replica creates a second volume, and enable_replica creates a
replication relationship between the two volumes.
Are the plugin's enable/disable method intended for just a one-time
start and
stop of the replication or are they expected to be able to cleanly pause
and
resume the replication process? Is disable expected to flush volume
contents
all the way through to the replica?
As of now you can assume that create_replica and enable_replica are called
together, and disable_replica and delete_replica are also called together,
in those orders. So if we call disable_replica you can assume we are
getting rid of the replica.
Another question is what is the expected usage of
primary_replication_unit_id
and secondary_replication_unit_id in the replication_relationships
table.
Are these optional? Are they the type of fields that could go in the
driver_data
field for the relationship?
Those two fields are filled in automatically - see replication_update_db()
in scheduler/driver.py
They simply hold whatever the driver returns in 'replication_unit_id',
which will likely be needed by drivers to know who the other side is.
In addition, you can put whatever you like driver_data to implement
replication for you backend.
Thanks,
Avishay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
