<div dir="ltr"><div>+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 :)<br><br></div>Best regards,<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Pavlo Shchelokovskyy<div>Software Engineer</div><div>Mirantis Inc</div><div><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a></div></div></div></div>
<br><div class="gmail_quote">On Tue, Feb 3, 2015 at 6:48 AM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think incremental adoption is a great principle to have and this<br>
will enable that.<br>
<br>
So +1<br>
<br>
-Rob<br>
<div class="HOEnZb"><div class="h5"><br>
On 3 February 2015 at 13:52, Steve Baker <<a href="mailto:sbaker@redhat.com">sbaker@redhat.com</a>> wrote:<br>
> A spec has been raised to add a config option to allow operators to choose<br>
> whether to use the new convergence engine for stack operations. For some<br>
> context you should read the spec first [1]<br>
><br>
> Rather than doing this, I would like to propose the following:<br>
> * Users can (optionally) choose which engine to use by specifying an engine<br>
> parameter on stack-create (choice of classic or convergence)<br>
> * Operators can set a config option which determines which engine to use if<br>
> the user makes no explicit choice<br>
> * Heat developers will set the default config option from classic to<br>
> convergence when convergence is deemed sufficiently mature<br>
><br>
> I realize it is not ideal to expose this kind of internal implementation<br>
> detail to the user, but choosing convergence _will_ result in different<br>
> stack behaviour (such as multiple concurrent update operations) so there is<br>
> an argument for giving the user the choice. Given enough supporting<br>
> documentation they can choose whether convergence might be worth trying for<br>
> a given stack (for example, a large stack which receives frequent updates)<br>
><br>
> Operators likely won't feel they have enough knowledge to make the call that<br>
> a heat install should be switched to using all convergence, and users will<br>
> never be able to try it until the operators do (or the default switches).<br>
><br>
> Finally, there are also some benefits to heat developers. Creating a whole<br>
> new gate job to test convergence-enabled heat will consume its share of CI<br>
> resource. I'm hoping to make it possible for some of our functional tests to<br>
> run against a number of scenarios/environments. Being able to run tests<br>
> under classic and convergence scenarios in one test run will be a great help<br>
> (for performance profiling too).<br>
><br>
> If there is enough agreement then I'm fine with taking over and updating the<br>
> convergence-config-option spec.<br>
><br>
> [1]<br>
> <a href="https://review.openstack.org/#/c/152301/2/specs/kilo/convergence-config-option.rst" target="_blank">https://review.openstack.org/#/c/152301/2/specs/kilo/convergence-config-option.rst</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>