Open Stack

On Thu, Nov 8, 2012 at 2:02 AM, Avishay Traeger <AVISHAY at il.ibm.com> wrote:

>
> Hi all,
> I had a few questions about snapshot support in Cinder:
> 1) a. Why is a snapshot a fundamentally different entity than a volume?
>    b. Is it because some back-ends don't support the same set of operations
> on snapshots?
>    c. Is this what the snapshot-to-volume operation was meant to achieve?
>    d. If a back-end supports nested snapshots, each snapshot will need to
> be converted to volume before a nested snapshot can be taken?
>    e. And in this case, will the back-end driver simply do nothing for the
> snapshot-to-volume operation?
> 2) Why can't you take snapshots of attached volumes?  I think most/all
> back-ends will be fine with it (of course they will be crash-consistent if
> the OS/application doesn't sync to disk).
> 3) Most back-ends support various types of snapshots - e.g., read-only,
> read-write, full copy, etc.  How can we better support this notion?
>
> Thanks,
> Avishay
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>

Hi Avishay,

So we have plans to improve some of this in the Grizzly release, here's a
few thoughts:
>> a. Why is a snapshot a fundamentally different entity than a volume?
I've asked this question a number of times myself :)  There are a number of
different ideas/definitions of what a snapshot is, versus a clone, versus a
backup, etc etc

I've proposed that we leave snapshots as they are today and introduce a
clone option to just directly get a new volume to work with and move on, as
well as the ability to restore a volume to a specific snapshot (the
originating volume, not a new one).  I don't know how popular this idea is
though, there were a number of folks at the Summit that seemed to think
that was crazy talk.

>> c. Is this what the snapshot-to-volume operation was meant to achieve?
Yep

>> d. If a back-end supports nested snapshots, each snapshot will need to
>> be converted to volume before a nested snapshot can be taken?
>> e. And in this case, will the back-end driver simply do nothing for the
>> snapshot-to-volume operation?
Not sure I follow here...

>>2) Why can't you take snapshots of attached volumes?  I think most/all
>>back-ends will be fine with it (of course they will be crash-consistent if
>>the OS/application doesn't sync to disk).
Worth investigating for those back-ends that support it

>>3) Most back-ends support various types of snapshots - e.g., read-only,
>>read-write, full copy, etc.  How can we better support this notion?
Not sure how I feel about trying to match up to every option every vendor
might have.  The reality also is that there are differences in definitions
from vendor A to vendor B on these sorts of things.

The direction I was going with snapshots, clones would *kinda* give at
least part of what you're talking about here.

I started a blueprint for this sort of thing here:
https://blueprints.launchpad.net/cinder/+spec/add-cloning-support-to-cinder,
feel free to add suggestions or give me feed-back if you like.  It's by no
means complete, but I should be working on it week after next.

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121108/313c5fe1/attachment.html>