Must a volume snapshot depend on a volume?

[Vincent Hou]

If a volume snapshot is created from a volume, the volume is unable to be deleted if the snapshot is still active. Can this volume snapshot live independent of this volume?

[John Griffith (john-griffith)]

Hi Vincent, so treating this as a question... the answer is that currently NO the snapshots are tied to the originating volume. Depending on the storage back and and how they've implemented snapshot functionality this is a requirement.

There is a bug that is intended to modify this such that it can be configured depending on the back-end being used or even better perhaps we can just make the decision intelligently and log a useful message.

https://review.openstack.org/#/c/9608/

[John Griffith (john-griffith)]

What the??? My link above is WRONG!!!! Should be: https://bugs.launchpad.net/cinder/+bug/970409

[Fergal Mc Carthy (fergal-mccarthy)]

As I said in bug #970409, I don't believe that this is a duplicate of that bug, and in fact the issue referenced here raises a very valid concern.

Currently to be able to make use of a snapshot you need both the information recorded for the snapshot in the snapshots table _*and*_ the information recorded for the the associated volume in the volumes table, specifically the provider location and auth fields.

Without that associated volume entry in the volumes table you will not have access to the provider information that is generally going to be needed to access a snapshot if you ever plan on creating a new volume from it.

So even if the back end storage solution supports the deletion of volumes that have associated snapshots we _*can't*_ actually allow those volume's entries to be deleted from the volumes table if there are associated snapshots because doing so would most likely render the snapshots inaccessible.

A relatively simple solution would be to add provider location and auth fields to the snapshots table, like those found in the volumes table. This would allow an entry in the volumes table to be deleted if the back end supports it since any related entries in the snapshots table will have their own independent copy of the provider info.

Additionally this would potentially have an added advantage in that it would allow a snapshot to have different provider information than the originating volume, which in turn might permit more efficient access to the snapshot in the case where a back end storage solution supports direct access to a snapshot.

Fergal.

[Fergal Mc Carthy (fergal-mccarthy)]

After a discussion with John Griffith we managed to reach a consensus of understanding about what I was getting at.

Basically my concern is that the provider location info is maintained only in the volumes table meaning that an entry in the snapshots table is potentially useless unless we keep the associated entry in the volumes table around.

This means that even when a back end supports deleting a volume that has associated snapshots right we can't actually delete the entry from the volumes table - we are required to keep the relevant entry around in volumes table, and at best we can mark it as deleted, leading to a bloating of the volumes table.

John suggested that my concerns may actually line up with the work being done by Chris McGowan from Piston Cloud in the area of "Making a snapshot just a special case of Volume".

Fergal.

[Rongze Zhu (zrzhit)]

If a snapshot just a special case of volume, volume can be divided into
* rw: normal volume
* r-: only read snapshot
* --: normal snapshot

Another question, if we have only read volume, Can the volume be shared by many instances?

[John Griffith (john-griffith)]

As it stands today in the code a snapshot is not really "just a special case" of a volume. Even if from a user perspective that's the case, in the code currently they are in fact unique.

This is something to consider for Grizzly.