> If this is in a release, we then need to maintain that feature, so would be > against it. Isn't the argument that cep-21 provides this so we could just remove the temporary impl and point to the new facility for this generation?
On Fri, Mar 24, 2023, at 3:22 PM, David Capwell wrote: >> the question we want to answer is whether or not we build a throwaway patch >> for linearizable epochs > > If this is in a release, we then need to maintain that feature, so would be > against it. > > If this is for testing, then I would argue the current world is “fine”… > current world is hard to use and brittle (users need to tell accord that the > cluster changed), but if accord is rebasing on txn metadata then this won’t > be that way long (currently blocked from doing that due to txn metadata not > passing all tests yet). > >> On Mar 24, 2023, at 12:12 PM, Josh McKenzie <jmcken...@apache.org> wrote: >> >>> FWIW, I'd still rather just integrate w/ TCM ASAP, avoiding integration >>> risk while accepting the possible delivery risk. >> What does the chain of rebases against trunk look like here? cep-21-tcm >> rebase, then cep-15 on cep-21-tcm, then cep-7 on cep-21-tcm, then a race on >> whichever of 15 or 7 merge after 21 goes into trunk? Or 7 based on 15, the >> other way around... >> >> I'm not actively working on any of these branches so take my perspective >> with that appropriate grain of salt, but the coupling of these things seems >> to have it's own kind of breed of integration pain to upkeep over time >> depending on how frequently we're rebasing against trunk. >> >>> the question we want to answer is whether or not we build a throwaway patch >>> for linearizable epochs >> Do we have an informed opinion on how long we think this would take? Seems >> like that'd help clarify whether or not there's contributors with the >> bandwidth and desire to even do that or whether everyone depending on cep-21 >> is our option. >> >> On Fri, Mar 24, 2023, at 1:30 PM, Caleb Rackliffe wrote: >>> I actually did a dry run rebase of cep-15-accord on top of cep-21-tcm here: >>> https://github.com/apache/cassandra/pull/2227 >>> >>> It wasn't too terrible, and I was actually able to get the main CQL-based >>> Accord tests working as long as I disabled automatic forwarding of CAS and >>> SERIAL read operations to Accord. The bigger issue was test stability in >>> cep-21-tcm. I'm sure that will mature quickly here, and I created a few >>> issues to attach to the Transactional Metadata epic >>> <https://issues.apache.org/jira/browse/CASSANDRA-18330>. >>> >>> In the meantime, I rebased cep-15-accord on trunk at commit >>> 3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de. The option to finish the >>> remaining bits of CASSANDRA-18196 >>> <https://issues.apache.org/jira/browse/CASSANDRA-18196> and merge w/o TCM >>> is still available, but it sounds like the question we want to answer is >>> whether or not we build a throwaway patch for linearizable epochs in lieu >>> of TCM? >>> >>> FWIW, I'd still rather just integrate w/ TCM ASAP, avoiding integration >>> risk while accepting the possible delivery risk. >>> >>> On Fri, Mar 24, 2023 at 9:32 AM Josh McKenzie <jmcken...@apache.org> wrote: >>>> __ >>>>> making sure that joining and leaving nodes update some state via Paxos >>>>> instead of via gossip >>>> What kind of a time delivery risk does coupling CEP-15 with CEP-21 >>>> introduce (i.e. unk-unk on CEP-21 leading to delay cascades to CEP-15)? >>>> Seems like having a table we CAS state for on epochs wouldn't be *too >>>> *challenging, but I'm not familiar w/the details so I could be completely >>>> off here. >>>> >>>> Being able to deliver both of these things on their own timetable seems >>>> like a pretty valuable thing assuming the lift required would be modest. >>>> >>>> On Fri, Mar 24, 2023, at 6:15 AM, Benedict wrote: >>>>> >>>>> Accord doesn’t have a hard dependency on CEP-21 fwiw, it just needs >>>>> linearizable epochs. This could be achieved with a much more modest >>>>> patch, essentially avoiding almost all of the insertion points of cep-21, >>>>> just making sure that joining and leaving nodes update some state via >>>>> Paxos instead of via gossip, and assign an epoch as part of the update. >>>>> >>>>> It would be preferable to use cep-21 since it introduces this >>>>> functionality, and our intention is to use cep-21 for this. But it isn’t >>>>> a hard dependency. >>>>> >>>>> >>>>>> On 22 Mar 2023, at 20:58, Henrik Ingo <henrik.i...@datastax.com> wrote: >>>>>> >>>>>> Since Accord depends on transactional meta-data... is there really any >>>>>> alternative than what you propose? >>>>>> >>>>>> Sure, if there is some subset of Accord that could be merged, while work >>>>>> continues on a branched that is based on CEP-21 branch, that would be >>>>>> great. Merging even a prototype of Accord to trunk probably has >>>>>> marketing value. (Don't laugh, many popular databases have had "atomic >>>>>> transactions, except if anyone executes DDL simultaneously".) >>>>>> >>>>>> On Tue, Mar 14, 2023 at 8:39 PM Caleb Rackliffe >>>>>> <calebrackli...@gmail.com> wrote: >>>>>>> We've already talked a bit >>>>>>> <https://lists.apache.org/list?dev@cassandra.apache.org:2023-1:Merging%20CEP-15%20to%20trunk> >>>>>>> about how and when the current Accord feature branch should merge to >>>>>>> trunk. Earlier today, the cep-21-tcm branch was created >>>>>>> <https://lists.apache.org/thread/qkwnhgq02cn12jon2h565kh2gpzp9rry> to >>>>>>> house ongoing work on Transactional Metadata. >>>>>>> >>>>>>> Returning to CASSANDRA-18196 >>>>>>> <https://issues.apache.org/jira/browse/CASSANDRA-18196> (merging Accord >>>>>>> to trunk) after working on some other issues, I want to propose >>>>>>> changing direction slightly, and make sure this makes sense to everyone >>>>>>> else. >>>>>>> >>>>>>> 1.) There are a few minor Accord test issues in progress that I'd like >>>>>>> to wrap up before doing anything, but those shouldn't take long. (See >>>>>>> CASSANDRA-18302 <https://issues.apache.org/jira/browse/CASSANDRA-18302> >>>>>>> and CASSANDRA-18320 >>>>>>> <https://issues.apache.org/jira/browse/CASSANDRA-18320>.) >>>>>>> 2.) Accord logically depends on Transactional Metadata. >>>>>>> 3.) The new cep-21-tcm branch is going to have to be rebased to trunk >>>>>>> on a regular basis. >>>>>>> >>>>>>> So... >>>>>>> >>>>>>> 4.) I would like to pause merging cep-15-accord to trunk, and instead >>>>>>> rebase it on cep-21-tcm until such time as the latter merges to trunk, >>>>>>> at which point cep-15-accord can be rebased to trunk again and then >>>>>>> merged when ready, nominally taking up the work of CASSANDRA-18196 >>>>>>> <https://issues.apache.org/jira/browse/CASSANDRA-18196> again. >>>>>>> >>>>>>> Any objections to this? >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> *Henrik Ingo* >>>>>> >>>>>> *c*. +358 40 569 7354 >>>>>> >>>>>> *w*. _www.datastax.com_ >>>>>>
