openstack team mailing list archive

[Avishay Traeger <AVISHAY@xxxxxxxxxx>]

John Griffith <john.griffith@xxxxxxxxxxxxx> wrote on 08/11/2012 19:58:39:
> 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

Hi John,
Thanks for your reply.  I guess I'm still confused about what a snapshot is
in OpenStack.  Currently you can't really do anything with them via
OpenStack.  I think every back-end supports reads, so at the very minimum,
why not allow attaching a snapshot to a VM in read-only mode?  Further, I
think all current back-ends support writable snapshots, so we could
consider attaching read-write, or making that a capability.

The way I'm thinking about it now is that volumes are stand-alone (i.e.,
full copies with no CoW mappings or any other dependencies), while
snapshots may depend on their respective source volumes.  I guess clones,
then, would be a full copy of the original volume, and would basically be a
shortcut for snapshot + create_volume_from_snapshot.  Do you agree?

And finally, with regard to supporting various types of snapshots - maybe
we can do something similar as with volume types?

Thanks,
Avishay