Snapshot as full objects
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.
