Enabling replication support during volume retype and migration

[Vincent Hou]

As far as we enable volume replication V2 support, four new replication V2 APIs are introduced.

At the same time, it is easy and straightforward for each driver to enable the replication when creating volume, creating volume from snapshot and cloning volume.

Are we also going to enable the replication for volume migration and retype?
There are several approaches:
1) We won't support replication for migration and retype, because it is too complex so far. We need to take care of many cases like retyping from one back-end to another, from one vendor to another, between the same vendor driver or back-end, etc. Update the doc, saying that if you want to make replication supported after volume retype or migration, you need to run enable-replication manually. If you do not want to support replication after volume retype or migration, you need to run disable-replication manually.

2) Support replication for migration and retype. In order to cover all the cases mentioned above, we do not need each driver to do it in one's own way. We can check if the replication is configured with the new volume type in cinder.volume.manager. If replication is available, run the code of enable-replication. If replication is not available in the volume type, run the code of disable-replication.
Even if replication V2 is not implemented for some drivers, there is nothing to loose for them.

[Sean McGinnis (sean-mcginnis)]

Unassigning due to no activity.

[Sean McGinnis (sean-mcginnis)]

Each driver that supports replication should handle changes to those settings during a retype. If they do not, then I would consider it a bug in that driver.

This bug is too general and broad. I think if there are drivers that support replication that are not handing retyping correctly, individual bugs should be filed against those drivers to track that shortcoming and the fix.