Re: Moving CEP-15 forward

2021-10-15 Thread bened...@apache.org
Hi Jonathan,

This clarifying change has been incorporated.

If you both rescind your veto, we have time to rescue this vote.


From: Jonathan Ellis 
Date: Friday, 15 October 2021 at 19:11
To: dev 
Subject: Moving CEP-15 forward
Hi all,

We have had several discussions today as to how to move forward on CEP-15,
given that the first vote was vetoed by myself and Mick. From my side the
concern has been that the distributed transactions design space inherently
requires tradeoffs; Accord represents one set of those tradeoffs but I want
to make sure that what we do now makes it easier to add other
implementations representing other points in that design space, rather than
tightly coupling us to just one option as we have been to date.

I do think Accord is an interesting proposal that advances the state of the
art in material ways.  As Mick has pointed out, my veto was not intended to
block it as such, but to make sure that we spend the time necessary to
understand how it might fit into a longer term roadmap beyond the scope of
CEP-15 itself.

It was my assumption that we could afford to continue such discussions to
get further clarity while the Accord team continues to improve their
prototype. However, I've learned today via some background discussions that
not approving the CEP in fact blocks the team behind it from fully
committing to this work.

That's unfortunate, and I suspect frustrating.  To unblock things, I think
we can move forward if we can add the following language to the CEP, under
"Long Term".  (Some degree of pluggability is already implied by the goal
of replacing LWT, but this is worth making explicit.)

*This work shall be developed in a modular manner, to allow for coexistence
with other consensus protocols or transaction managers. This will allow us
to evolve Accord without precluding alternative solutions, as future work
expands Cassandra's transactional capabilities beyond the goals of this
CEP. Initially, supporting the Paxos-based LWT and Accord side by side is
also an example of such modularity and optionality.*

(For completeness, I note that explicitly adding pluggability as a
requirement means that it is no longer necessary to also add a LOCAL_SERIAL
option to Accord itself, although that is of course still an option.)

--
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced


Re: Moving CEP-15 forward

2021-10-15 Thread Nate McCall
On Sat, Oct 16, 2021 at 7:18 AM Jonathan Ellis  wrote:

> ...
> *This work shall be developed in a modular manner, to allow for coexistence
> with other consensus protocols or transaction managers. This will allow us
> to evolve Accord without precluding alternative solutions, as future work
> expands Cassandra's transactional capabilities beyond the goals of this
> CEP. Initially, supporting the Paxos-based LWT and Accord side by side is
> also an example of such modularity and optionality.*
>
>
This feels like a good compromise to me and I'm all for increasing
modularity where we can.

Cheers,
-Nate


Re: Moving CEP-15 forward

2021-10-15 Thread Paulo Motta
Amending the CEP with the proposed addendum seems to me like a reasonable
compromise to de-escalate this matter and move forward, addressing
potential concerns without any prejudice to the original goals of the CEP.

Em sex., 15 de out. de 2021 às 15:11, Jonathan Ellis 
escreveu:

> Hi all,
>
> We have had several discussions today as to how to move forward on CEP-15,
> given that the first vote was vetoed by myself and Mick. From my side the
> concern has been that the distributed transactions design space inherently
> requires tradeoffs; Accord represents one set of those tradeoffs but I want
> to make sure that what we do now makes it easier to add other
> implementations representing other points in that design space, rather than
> tightly coupling us to just one option as we have been to date.
>
> I do think Accord is an interesting proposal that advances the state of the
> art in material ways.  As Mick has pointed out, my veto was not intended to
> block it as such, but to make sure that we spend the time necessary to
> understand how it might fit into a longer term roadmap beyond the scope of
> CEP-15 itself.
>
> It was my assumption that we could afford to continue such discussions to
> get further clarity while the Accord team continues to improve their
> prototype. However, I've learned today via some background discussions that
> not approving the CEP in fact blocks the team behind it from fully
> committing to this work.
>
> That's unfortunate, and I suspect frustrating.  To unblock things, I think
> we can move forward if we can add the following language to the CEP, under
> "Long Term".  (Some degree of pluggability is already implied by the goal
> of replacing LWT, but this is worth making explicit.)
>
> *This work shall be developed in a modular manner, to allow for coexistence
> with other consensus protocols or transaction managers. This will allow us
> to evolve Accord without precluding alternative solutions, as future work
> expands Cassandra's transactional capabilities beyond the goals of this
> CEP. Initially, supporting the Paxos-based LWT and Accord side by side is
> also an example of such modularity and optionality.*
>
> (For completeness, I note that explicitly adding pluggability as a
> requirement means that it is no longer necessary to also add a LOCAL_SERIAL
> option to Accord itself, although that is of course still an option.)
>
> --
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced
>