Open Stack

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