Excerpts from Zane Bitter's message of 2015-02-06 06:25:57 -0800:
> On 03/02/15 14:12, Clint Byrum wrote:
> > The visible change in making things parallel was minimal. In talking
> > about convergence, it's become clear that users can and should expect
> > something radically different when they is
On 03/02/15 14:12, Clint Byrum wrote:
The visible change in making things parallel was minimal. In talking
about convergence, it's become clear that users can and should expect
something radically different when they issue stack updates. I'd love to
say that it can be done to just bind convergenc
Excerpts from Zane Bitter's message of 2015-02-03 10:00:44 -0800:
> On 02/02/15 19:52, Steve Baker 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
On 02/02/15 19:52, Steve Baker 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:
I
Excerpts from Angus Salkeld's message of 2015-02-03 02:40:44 -0800:
> On Tue, Feb 3, 2015 at 10:52 AM, Steve Baker 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 s
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
On Tue, Feb 3, 2015 at 10:52 AM, Steve Baker 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 prop
+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
M
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 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
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 eng
10 matches
Mail list logo