On Tue, Feb 3, 2015 at 10:52 AM, Steve Baker <sba...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
