+1, that would ease the development and also drive adoption IMO, as people could start using/experimenting with it earlier, and more eyes == less bugs. You can never predict all the ways how users would use and abuse your new shiny feature :)
Best regards, Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com On Tue, Feb 3, 2015 at 6:48 AM, Robert Collins <robe...@robertcollins.net> wrote: > I think incremental adoption is a great principle to have and this > will enable that. > > So +1 > > -Rob > > On 3 February 2015 at 13:52, 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). > > > > 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 > > > > -- > Robert Collins <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > __________________________________________________________________________ > 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