Re: [openstack-dev] [Heat] Stack snapshots
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 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 > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Stack snapshots
Hi Thomas, On Tue, Apr 15, 2014 at 01:16:50PM +0200, Thomas Herve 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? Firstly, thanks for picking this up - I raised that bp nearly a year ago after some use-case discussions with users, I think it we can make it work it should be a pretty interesting feature :) Re your questions, I've been thinking about it and I actually think there are two features, which could be independently implemented: 1. Stack snapshot, use the most lightweight approach to snapshotting the underlying resources, and store state in the heat DB, for easy roll-back to a previous state, e.g after one or more updates (e.g after the update has completed) 2. Stack backup, use persistent snapshot interfaces for the underlying resources, and store the state of the stack outside the DB, e.g in swift. I think this approach aligns most closely with existing snapshot/backup conventions (e.g cinder) and also provides the most flexibility for folks using the features. My thoughts originally were that you could take one or more snapshots (probably up to a fairly small limit per stack) and then trigger a special type of update, where an existing stack is restored to a previous state, this is the use-case which the users I spoke to described. The approach you describe where snapshots are more persistent also seems valid, but I think the creation action from backup data is actually a slightly different thing from stack-snapshot, and both could be useful. Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] Stack snapshots
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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
