Difference between revisions of "Snapshot as full objects"
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. | ||
This is part of the [[CERSS]] initiative. | This is part of the [[CERSS]] initiative. |
Revision as of 18:44, 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.
This is part of the CERSS initiative.