106c14a84b
This focuses the replication work on a specific use case, and eliminates some of the ambiguity in earlier versions. Additionally this implementation addresses needs for devices that do replication based on the whole backend-device or on Pools. Use case: DR scenario, where a storage device is rendered inoperable. This implementation allows the preservation of user data for those volumes that are of type replication-enabled. The goal is NOT to make failures completely transparent but instead to preserve data access while an Admin tries to rebuild/recover his/her cloud. It's very important to note that we're no longer interested in dealing with replication in Cinder at a Volume level. The concept of have "some" volumes failover, and "others" left behind, proved to not only be overly complex and difficult to implement, but we never identified a concrete use-case where one would use failover in a scenario where some volumes would stay and be accessible on a primary but other may be moved and accessed via a secondary. In this model, it's host/backend based. So when you failover, you're failing over an entire backend. We heavily leverage existing resources, specifically services, and capabilities. Implements: blueprint replication-update Change-Id: If862bcd18515098639f94a8294a8e44e1358c52a
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