Jump to: navigation, search

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.