Open Stack

Excerpts from Angus Salkeld's message of 2014-09-22 20:15:43 -0700:
> On Tue, Sep 23, 2014 at 1:09 AM, Anant Patil <anant.patil at hp.com> wrote:
> 
> > Hi,
> >
> > One of the steps in the direction of convergence is to enable Heat
> > engine to handle concurrent stack operations. The main convergence spec
> > talks about it. Resource versioning would be needed to handle concurrent
> > stack operations.
> >
> > As of now, while updating a stack, a backup stack is created with a new
> > ID and only one update runs at a time. If we keep the raw_template
> > linked to it's previous completed template, i.e. have a back up of
> > template instead of stack, we avoid having backup of stack.
> >
> > Since there won't be a backup stack and only one stack_id to be dealt
> > with, resources and their versions can be queried for a stack with that
> > single ID. The idea is to identify resources for a stack by using stack
> > id and version. Please let me know your thoughts.
> >
> 
> Hi Anant,
> 
> This seems more complex than it needs to be.
> 
> I could be wrong, but I thought the aim was to simply update the goal state.
> The backup stack is just the last working stack. So if you update and there
> is already an update you don't need to touch the backup stack.
> 
> Anyone else that was at the meetup want to fill us in?
> 

The backup stack is a device used to collect items to operate on after
the current action is complete. It is entirely an implementation detail.

Resources that can be updated in place will have their resource record
superseded, but retain their physical resource ID.

This is one area where the resource plugin API is particularly sticky,
as resources are allowed to raise the "replace me" exception if in-place
updates fail. That is o-k though, at that point we will just comply by
creating a replacement resource as if we never tried the in-place update.

In order to facilitate this, we must expand the resource data model to
include a version. Replacement resources will be marked as "current" and
to-be-removed resources marked for deletion. We can also keep all current
- 1 resources around to facilitate rollback until the stack reaches a
"complete" state again. Once that is done, we can remove the backup stack.