Open Stack

I really like some benefits of this approach:
 - easy use in functional tests (did not require additional job)
 - every user can try from this moment
 - we can use both code ways in the same time without service restarting

So I really close to give my +1, if someone give answers on questions from
other side:
 - as Angus said, how we plan deprecate it then (when new code will become
default) more softer for users?
 - As I understand the parameter option will have upper priority then
config.
   so operator has not way to block it from users and they should decide
themselves what they want (what is more safely)? (and of course choose new,
because it sounds better)
 - I really afraid, that some users will start use new option and will be
disappointed, due to they expect a lot of benefits, but the reality will be
different.
   IMO, exposing so young feature looks cool for development part and
gathering feedback, but dangerous for "stable" product users + bad example
of commercial.

If somebody help me to remove these doubts, I will be thankful to him :)

Regards,
Sergey.

On 3 February 2015 at 03: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150203/9928d5da/attachment.html>