John Griffith <john.griff...@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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
