Re: [openstack-dev] [Heat] Stack snapshots

2014-04-17 Thread Duncan Thomas
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

2014-04-17 Thread Steven Hardy
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

2014-04-15 Thread Thomas Herve
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