Open Stack

On Sun, Nov 11, 2012 at 6:30 AM, Avishay Traeger <AVISHAY at il.ibm.com> wrote:

> John Griffith <john.griffith at solidfire.com> 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
>
> Hey Avishay,

>>I guess I'm still confused about what a snapshot is
>>in OpenStack.  Currently you can't really do anything with them via
>>OpenStack.
Sure you can, you can use them to create a new volume.  They make a good
backup mechanism IMO.

I guess my question to you in your definition then is 'what's the
difference between a snapshot and a clone'?

Also, it Seems to me if we go with the idea of adding snapshot-restore, and
a true "clone" feature you get everything that you're asking for here and
more... so I'm not sure of the problem?  Maybe you could help me understand
why defining snapshot and clone in the manner described doesn't seem
appropriate?

FWIW, I think a R/O attach is something that would be good to have as an
option regardless.

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