Volume Replication
The goal is to improve the resiliency of data by enabling Cinder to manage the replication of volumes. The replication of the data is done by the storage backends. Replication is controlled via volume types, and is transparent to the user (both in terms of visibility and maintenance). A detailed design is included in the attached etherpad.
Blueprint information
- Status:
- Complete
- Approver:
- John Griffith
- Priority:
- Low
- Drafter:
- Avishay Traeger
- Direction:
- Approved
- Assignee:
- Avishay Traeger
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Needs Code Review
- Milestone target:
-
next
- Started by
- Avishay Traeger
- Completed by
- Sean McGinnis
Related branches
Related bugs
Sprints
Whiteboard
(smcginnis): Marking obsolete as this has been sitting out there for a long time. If this is still needed, please submit a new bp.
Gerrit topic: https:/
Addressed by: https:/
Volume replication
Gerrit topic: https:/
<jdg>
Based on quite a bit of feedback we need to step back and take a closer look at our design for this feature. Currently nobody has had a chance to implement it anyway and it's not implemented in the reference driver so it seems like it would be good to take a look at resolving design concerns and focusing on a workable solution for more than just one driver.
<thingee>:
Is this transparent to the user in hopes they don't notice when the admin is doing manual interventions to bring degraded volume back?
<emh>
This blueprint is dead/obsolete. [Feb 2015]
