In my opinion, a similar calculus should be applied to 3.0 and 3.11. This is
a(n arguably quite serious) bug, so whatever is not overly onerous to backport
should be considered while they are supported. The work under discussion has
two components: a replacement to the core consensus algorithm, and mechanisms
to ensure safety across range movements. The latter might be more invasive for
3.x, but the former should be quite easy to backport and as such probably quite
well justified.
> can it also pluggable (either opt-in or opt-out)?
I think pluggable means something different to opt-in/opt-out, at least to me.
I'm all for more pluggability, and also for more optionality, but the decision
is very sensitive to context. We need to be able to select between our options,
which for consensus practically means supporting live migration - which is
exceptionally challenging in any general sense (and perhaps inherently
non-pluggable).
As to future development for consensus, I personally hope the work we are
discussing here will be a strong platform for it, but obviously that's for the
community to decide later on. I think the work to take it forwards to something
epaxos-like will not be that herculean, with some incremental milestones en
route. But that's a totally different discussion for the future, and either a
CEP or a small intercollegiate working group.
On 11/11/2020, 18:48, "Michael Semb Wever" <m...@apache.org> wrote:
> Regarding CASSANDRA-12126 and 4.0 we are facing several options and
> Benedict, Sylvain and I wanted to get the community feedback on them.
>
> We can:
>
> 1. Try to use Benedict proposal for 4.0 if the community has the
> appetite for it. The main issue there is some potential extra delay
for 4.0
> 2. Do nothing for 4.0. Meaning do not commit the current patch. We have
> lived a long time with that issue and we can probably wait a bit more
for a
> proper solution.
> 3. Commit the patch as such, fixing the correctness but introducing
> potentially some performance issue until we release a better solution.
> 4. Changing the patch to default to the current behavior but allowing
> people to enable the new one if the correctness is a problem for them.
>
If these options are for 4.0, is it then (4) that it is getting applied to
3.0 and 3.11 ?
If that is the case then I would vote on also applying (4) to 4.0, given we
are now in front of beta4. Please let's not further delay 4.0.
Post 4.0, if (1) is as described "a parallel implementation of the same
underlying Paxos algorithm" can it also pluggable (either opt-in or opt-out)?
And would/could EPaxos become pluggable too in a similar manner (if it
eventuates)? I'm in favour on providing more pluggable interfaces into C*,
along with the code quality improvements that's going to have to be accompanied
with.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
