fe538dc63d
This adds a scaled back replication implementation
that leaves the bulk of the work up to the driver.
We just provide basic admin API methods to do things
like enable/disable and fail-over. Set up and
specification of replication targets for a specific
back end are now intended to be part of the cinder.conf
in the driver section itself.
Replication targets are configured via the cinder.conf
file in their associated driver section. See the devref
doc included in this commit for details on the format.
The next step in configuration is to create a volume-type
with replication info in the extra-specs.
extra-specs = replication=enable, volume_backend_name=foo
This instructs the driver to utilize replication, default is
up to the driver but would suggest single way rep and in the case
of multiple targets, driver could choose or have a default.
If the back end doesn't report replication=enabled in it's stats
updates the scheduler will fail to place the volume due to invalid
host, or no hosts available.
Vendors can easily modify extra-specs or their own config settings
to modify this behavior, any vendor-unique adaptation can be
provided through the use of scoped keys. Suggested examples
will be published in docs.
See doc/source/devref/replication.rst for more info
Implements BP: replication-v2
DocImpact
Change-Id: I406390e4d5f3c9947df1c4f2de68821e0fd7f75b
CINDER
You have come across a storage service for an open cloud computing service. It has identified itself as Cinder. It was abstracted from the Nova project.
- Wiki: http://wiki.openstack.org/Cinder
- Developer docs: http://docs.openstack.org/developer/cinder
Getting Started
If you'd like to run from the master branch, you can clone the git repo:
git clone https://github.com/openstack/cinder.git
For developer information please see HACKING.rst
You can raise bugs here http://bugs.launchpad.net/cinder