Open Stack

+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 <robertc at 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 <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).
> >
> > 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
>
>
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> __________________________________________________________________________
> 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/4a8a2b34/attachment.html>