Difference between revisions of "Snapshot as full objects"
| (One intermediate revision by the same user not shown) | |||
| Line 8: | Line 8: | ||
* 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. | ||
| + | |||
| + | The states of a snapshot as created using ZFS are very simple: | ||
| + | * Full Snapshot: as created. | ||
| + | * Pending Delete: the user has deleted this snapshot but it is still referenced by a later incremental snapshot. | ||
| + | * Inbound: This snapshot has been created on this backend as a target of a snapshot replication. The snapshot is not yet usable, however. | ||
| + | |||
| + | |||
| + | Other Volume Drivers may need to identify additional states. For example, an implementation might have a "Creating" state where a | ||
| + | snapshot is in the process of being created, but where it cannot yet be used to clone a new volume. | ||
| + | |||
| + | To be confirmed: I suspect that an optional flag indicating that this was a temporary snapshot which would be imminently deleted would be useful on snapshot create. | ||
| + | An implementation which just journaled the updates to the volume while the original volume served as a read-only volume would be able to omit the step of starting | ||
| + | to replicate the original volume when it new that the state of having a snapshot was only temporary. | ||
This is part of the [[CERSS]] initiative. | This is part of the [[CERSS]] initiative. | ||
Latest revision as of 22:13, 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.
The states of a snapshot as created using ZFS are very simple:
- Full Snapshot: as created.
- Pending Delete: the user has deleted this snapshot but it is still referenced by a later incremental snapshot.
- Inbound: This snapshot has been created on this backend as a target of a snapshot replication. The snapshot is not yet usable, however.
Other Volume Drivers may need to identify additional states. For example, an implementation might have a "Creating" state where a
snapshot is in the process of being created, but where it cannot yet be used to clone a new volume.
To be confirmed: I suspect that an optional flag indicating that this was a temporary snapshot which would be imminently deleted would be useful on snapshot create. An implementation which just journaled the updates to the volume while the original volume served as a read-only volume would be able to omit the step of starting to replicate the original volume when it new that the state of having a snapshot was only temporary.
This is part of the CERSS initiative.
