Open Stack

Excerpts from Angus Salkeld's message of 2015-02-03 02:40:44 -0800:
> On Tue, Feb 3, 2015 at 10:52 AM, Steve Baker <sbaker at redhat.com> wrote:
> 
> > A spec has been raised to add a config option to allow operators to choose
> > whether to use the new convergence engine for stack operations. For some
> > context you should read the spec first [1]
> >
> > Rather than doing this, I would like to propose the following:
> > * Users can (optionally) choose which engine to use by specifying an
> > engine parameter on stack-create (choice of classic or convergence)
> > * Operators can set a config option which determines which engine to use
> > if the user makes no explicit choice
> > * Heat developers will set the default config option from classic to
> > convergence when convergence is deemed sufficiently mature
> >
> > I realize it is not ideal to expose this kind of internal implementation
> > detail to the user, but choosing convergence _will_ result in different
> > stack behaviour (such as multiple concurrent update operations) so there is
> > an argument for giving the user the choice. Given enough supporting
> > documentation they can choose whether convergence might be worth trying for
> > a given stack (for example, a large stack which receives frequent updates)
> >
> > Operators likely won't feel they have enough knowledge to make the call
> > that a heat install should be switched to using all convergence, and users
> > will never be able to try it until the operators do (or the default
> > switches).
> >
> > Finally, there are also some benefits to heat developers. Creating a whole
> > new gate job to test convergence-enabled heat will consume its share of CI
> > resource. I'm hoping to make it possible for some of our functional tests
> > to run against a number of scenarios/environments. Being able to run tests
> > under classic and convergence scenarios in one test run will be a great
> > help (for performance profiling too).
> >
> 
> Hi
> 
> I didn't have a good initial response to this, but it's growing on me. One
> issue is the specific option that we expose, it's not nice having
> a dead option once we totally switch over and remove "classic". So is it
> worth coming up with a real feature that convergence-phase-1 enables
> and use that (like enable-concurrent-updates). Then we need to think if we
> would actually want to keep that feature around (as in
> once "classic" is gone is it possible to maintain
> "disable-concurrent-update").
> 

There are other features of convergence that will be less obvious.
Having stack operations survive a restart of the engines is a pretty big
one that one might have a hard time grasping, but will be appreciated by
users. Also being able to push a bigger stack in will be a large benefit,
though perhaps not one that is realized on day 1.

Anyway, I'd prefer that they just be versioned, and not named. The names
are too implementation specific. A v1 stack will be expected to work
with v1 stack tested templates and parameters for as long as we support
v1 stacks.

A v2 stack will be expected to work similarly, but may act differently,
and thus a user can treat this as another API update that they need to
deal with. The features will be a force multiplier, but the recommendation
of the team by removing the "experimental" tag will be the primary
motivator. And for operators, when they're comfortable with new stacks all
going to v2 they can enable that as the default. If they trust the Heat
developers, they can just go to v2 as default when the Heat devs say so.

Once we get all of the example templates to work with v2 and write some
new v2-specific stacks, thats the time to write a migration tool and
deprecate v1.

So, to be clear, I'm fully in support of Steve Baker's suggestion to let
the users choose which engine to use. However, I think we should treat
it not as an "engine" choice, but as an "interface" choice. The fact that
it takes a whole new engine to support the new features of the interface
is the implementation detail that no end-user needs to care about.