Difference between revisions of "Snapshot as full objects"
Line 4: | Line 4: | ||
* defining a "snapshot replicate" method which can replicate a snapshot to another storage backend with the same type of Volume Driver. | * defining a "snapshot replicate" method which can replicate a snapshot to another storage backend with the same type of Volume Driver. | ||
− | Optionally allowing the Volume Driver to direct storage-backend to storage-backend transfer of snapshots. | + | * Optionally allowing the Volume Driver to direct storage-backend to storage-backend transfer of snapshots. |
− | |||
* Allowing a snapshot to be dependent on a prior snapshot of the same volume stored on the same backend. | * Allowing a snapshot to be dependent on a prior snapshot of the same volume stored on the same backend. | ||
* Allowing Volumes to be dependent on the snapshot they were cloned from. | * Allowing Volumes to be dependent on the snapshot they were cloned from. | ||
* Allowing time consuming operations involved in creating/replicating a snapshot to be tracked in the Snapshot status. | * Allowing time consuming operations involved in creating/replicating a snapshot to be tracked in the Snapshot status. |
Revision as of 18:38, 18 November 2013
Currently there isn't a lot you can do with Snapshots in Cinder. You can create them. You can clone a volume from them. You can delete them.
The proposal is to make Snapshots first class Cinder objects by:
- defining a "snapshot replicate" method which can replicate a snapshot to another storage backend with the same type of Volume Driver.
- Optionally allowing the Volume Driver to direct storage-backend to storage-backend transfer of snapshots.
- Allowing a snapshot to be dependent on a prior snapshot of the same volume stored on the same backend.
- Allowing Volumes to be dependent on the snapshot they were cloned from.
- Allowing time consuming operations involved in creating/replicating a snapshot to be tracked in the Snapshot status.