<commit_before>..
 This work is licensed under a Creative Commons Attribution 3.0 Unported
 License.

 http://creativecommons.org/licenses/by/3.0/legalcode

==========================================
VolumeReplication_V2
==========================================

Include the URL of your launchpad blueprint:

https://blueprints.launchpad.net/cinder/+spec/replication-v2

This spec proposes Version 2 of replication.  The goal is to take
some of the lessons we've learned from the first version of
replication that was added in teh Juno release and see if we can
improve it a bit and make it something that is more widely usable
by other backend devices.

This spec proposes a use of our entire tool-box to implement replication.

1. Capabilities - determine if we can even do anything related to replication

2. Types/Extra-Specs - provide mechanism for vendor-unique custom info and
   help level out some of the unique aspects among the different back-ends.

3. API Calls - provide some general API calls for things like enable,
   disable etc

It would also be preferable to simplify the state management a bit if we can.


Problem description
===================
The current implementation is fairly complex and  has proven to be difficult
to implement for backend devices as well as difficult to maintain.  There
is also some concern around how states are managed and stored in the data
base.<commit_msg>Trival fix a typo<commit_after>..
 This work is licensed under a Creative Commons Attribution 3.0 Unported
 License.

 http://creativecommons.org/licenses/by/3.0/legalcode

==========================================
VolumeReplication_V2
==========================================

Include the URL of your launchpad blueprint:

https://blueprints.launchpad.net/cinder/+spec/replication-v2

This spec proposes Version 2 of replication.  The goal is to take
some of the lessons we've learned from the first version of
replication that was added in the Juno release and see if we can
improve it a bit and make it something that is more widely usable
by other backend devices.

This spec proposes a use of our entire tool-box to implement replication.

1. Capabilities - determine if we can even do anything related to replication

2. Types/Extra-Specs - provide mechanism for vendor-unique custom info and
   help level out some of the unique aspects among the different back-ends.

3. API Calls - provide some general API calls for things like enable,
   disable etc

It would also be preferable to simplify the state management a bit if we can.


Problem description
===================
The current implementation is fairly complex and  has proven to be difficult
to implement for backend devices as well as difficult to maintain.  There
is also some concern around how states are managed and stored in the data
base.
{'fraction_non_alphanumeric': 0.10615711252653928, 'fraction_numerical': 0.007077140835102618, 'mean_word_length': 4.436538461538461, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6179717', 'n_tokens_mistral': 705, 'n_tokens_neox': 651, 'n_words': 384}