Open Stack

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").

Regards
Angus


>
> If there is enough agreement then I'm fine with taking over and updating
> the convergence-config-option spec.
>
> [1] https://review.openstack.org/#/c/152301/2/specs/kilo/
> convergence-config-option.rst
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150203/05ac36cb/attachment.html>