Assuming we do not release with it, then yes, as we wouldn’t need to maintain. My point for this case was that I don’t feel the time cost is worth it, I am not -1 if someone wants to add, was more saying our time is better off else where.
We currently don’t touch Transactional Metadata, we have custom logic (which relies on client to tell every instance in the cluster an update happened) that we are using right now in tests and deployed clusters. So once we can integrate with Transactional Metadata, we stop relying on clients to tell us about topology changes… a custom/thrown away epoch generator would make this current process more user friendly, but would need to spend time to make sure stable when deployed on a cluster > On Mar 24, 2023, at 12:43 PM, Josh McKenzie <jmcken...@apache.org> wrote: > >> 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 >>>> <mailto: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 >>>>>> <mailto: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 <mailto: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 <http://www.datastax.com/>
