Re: Moving CEP-15 forward
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
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
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 >
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