I am +1 on Benjamin’s proposal
and less interruptions during upgrades. For more visibility maybe we can
also write a short article about the options and the tradeoffs, further to
NEWS.txt (that’s not something to decide now, of course :-) )
On Tue, 24 Nov 2020 at 9:13, Benjamin Lerer
wrote:
>
> Benedict suggested that Sylvain and I made the choice. Sylvain did not want
> to make the final call.
> I chose correctness. If it is a problem and people prefer to vote. It is
> perfectly fine for me too :-)
+1
Appreciate it having been raised for exposure and discussion Benjamin, and
Fair points. I retract the yaml suggestion and +1 to go with the
correctness route.
Em ter., 24 de nov. de 2020 às 11:13, Benjamin Lerer <
benjamin.le...@datastax.com> escreveu:
> Paulo, what you propose with the yaml seems different from default to
> *correctness*. It means to me that we are
Paulo, what you propose with the yaml seems different from default to
*correctness*. It means to me that we are forcing the user to choose
between *correctness *and *performance*. Most of us have a good
understanding of the problem and it is a hard choice for us. I imagine that
most of the users
> I think the keyword there is "normally" - if we can't say _certainly_,
> then this is probably an unsafe change to make.
>
> I can imagine any number of hacky upgrade processes that would be
> dangerous with this change.
>
I agree. We just don't know what users are doing, this is risky.
IMO
I think the keyword there is "normally" - if we can't say _certainly_, then
this is probably an unsafe change to make.
I can imagine any number of hacky upgrade processes that would be dangerous
with this change.
But, happy to defer to the consensus of others.
On 24/11/2020, 11:04, "Paulo
In this case the breaking change is a feature, not a bug. The exact
intention of this is to require manual intervention to raise awareness
about the potential performance degradation. This sounds reasonable, once
we already broke the contract of not introducing performance regressions in
a minor.
In my parlance the config property would be a breaking change, whereas the LWT
behaviour would be a performance regression. This latter might cause partial
outages or service degradation, but refusing to start a prod cluster without
manual intervention is potentially a much worse situation,
