<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 3, 2015 at 10:52 AM, Steve Baker <span dir="ltr"><<a href="mailto:sbaker@redhat.com" target="_blank">sbaker@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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]<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 parameter on stack-create (choice of classic or convergence)<br>
* Operators can set a config option which determines which engine to use if the user makes no explicit choice<br>
* Heat developers will set the default config option from classic to convergence when convergence is deemed sufficiently mature<br>
<br>
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)<br>
<br>
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).<br>
<br>
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).<br></blockquote><div><br></div><div>Hi<br><br></div><div>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<br></div><div>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<br></div><div>and use that (like enable-concurrent-updates). Then we need to think if we would actually want to keep that feature around (as in<br></div><div>once "classic" is gone is it possible to maintain "disable-concurrent-update").<br><br></div><div>Regards<br>Angus<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If there is enough agreement then I'm fine with taking over and updating the convergence-config-option spec.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/152301/2/specs/kilo/convergence-config-option.rst" target="_blank">https://review.openstack.org/#<u></u>/c/152301/2/specs/kilo/<u></u>convergence-config-option.rst</a><br>
<br>
______________________________<u></u>______________________________<u></u>______________<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.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br></div></div>