On Thu, Nov 8, 2012 at 2:02 AM, Avishay Traeger <[email protected]> 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 : [email protected] > 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
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
