]> review.fuel-infra Code Review - openstack-build/cinder-build.git/commit
Add support in Cinder for volume replication - driver approach
authorRonen Kat <ronenkat@il.ibm.com>
Sat, 26 Jul 2014 14:06:52 +0000 (17:06 +0300)
committerRonen Kat <ronenkat@il.ibm.com>
Sat, 23 Aug 2014 15:53:55 +0000 (15:53 +0000)
commit1c8f49bfe9fe3abd713e28922d5551f71228624c
treea6adebfb10cfb3c125cc4161efaa86352d70eb04
parent74a38b5e7ea69f9730845e71c34fafdb7733c60b
Add support in Cinder for volume replication - driver approach

This is take #2 for managing replicaiton in Cinder.

This patch provides the foundation in Cinder to make volume
replication available to the cloud admin. It makes Cinder aware
of volume replicas, and allows the cloud admin to define storage
policies (volume types) that will enable replication.

In this version Cinder delegates most the work on replication
to the driver itself.

This includes:
1. Driver exposes replication capabilities via volume type convention.
2. Extend volume table to include columns to support replicaion.
3. Create replicas in the driver, making it transparant to Cinder.
4. Volume manager code to handle API, updates to create_volume to
   support creating test replicas.
5. Driver methods to expose per replication functions

Cinder-specs available at https://review.openstack.org/#/c/98308/

Volume replication use-case: Simplified disaster recovery
The OpenStack cloud is deployed across two metro distance data centers.
Storage backends are available in both data ceneters. The backends
are managed by either a single Cinder host or two, depending on the
storage backend requirements.
Storage admin configures the Cinder volume driver to support
replication.
Cloud admin creates a volume type "replicated" with extra-specs:
   capabilities:replication="<is> True"
Every volume created in type "replicated" has a copy on both
backends.
In case of data center failure in first data center, the cloud admin
promotes the replica, and redeploy the VMs - they will now run on
a host in the secondary data center using the storage on the
secondary data center.

Implements: blueprint volume-replication
DocImpact

Change-Id: I964852f08b500400a27bff99e5200386e00643c9
29 files changed:
cinder/api/contrib/volume_replication.py [new file with mode: 0644]
cinder/api/v2/views/volumes.py
cinder/api/v2/volumes.py
cinder/common/config.py
cinder/db/sqlalchemy/migrate_repo/versions/024_add_replication_support.py [new file with mode: 0644]
cinder/db/sqlalchemy/models.py
cinder/exception.py
cinder/replication/__init__.py [new file with mode: 0644]
cinder/replication/api.py [new file with mode: 0644]
cinder/tests/api/contrib/test_admin_actions.py
cinder/tests/api/contrib/test_volume_replication.py [new file with mode: 0644]
cinder/tests/api/v2/stubs.py
cinder/tests/api/v2/test_volumes.py
cinder/tests/policy.json
cinder/tests/test_create_volume_flow.py
cinder/tests/test_migrations.py
cinder/tests/test_replication.py [new file with mode: 0644]
cinder/tests/test_volume.py
cinder/tests/test_volume_rpcapi.py
cinder/tests/utils.py
cinder/volume/api.py
cinder/volume/driver.py
cinder/volume/flows/api/create_volume.py
cinder/volume/flows/manager/create_volume.py
cinder/volume/manager.py
cinder/volume/rpcapi.py
cinder/volume/utils.py
etc/cinder/cinder.conf.sample
etc/cinder/policy.json