You're probably going to want to look at the proposals for volume consistency groups in cinder - backing up/snapshotting volumes independently is likely to cause issues with some applications, since different VMs will be in slightly different states, so you can get lost or duplicated work/records/etc
On 15 April 2014 12:16, Thomas Herve <[email protected]> wrote: > Hi all, > > I started working on the stack snapshot blueprint [1] and wrote a first > series of patches [2] to get a feeling of what's possible. I have a couple of > related design questions though: > > * Is a stack snapshot independent of the stack? That's the way I chose for > my patches, you start with a stack, but then you can show and delete > snapshots independently. The main impact will be how restoration works: is > restoration an update action on a stack towards a specific state, or a > creation action with backup data? > > * Consequently, should be use volume backups (which survive deleting of the > original volumes) or volume snapshots (which don't). If the snapshot is > dependent of the stack, then we can use the more efficient snapshot > operation. But backup is also an interesting use-case, so should it be > another action completely? > > > [1] https://blueprints.launchpad.net/heat/+spec/stack-snapshot > > [2] > https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/stack-snapshot,n,z > > Thanks, > > -- > Thomas > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- Duncan Thomas _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
