Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[Caleb Rackliffe]

Minimizing uncertainty is a nice abstract goal. What I worry about is that we ultimately create more of it (and more work/thrashing for ourselves) by not basing Accord on TCM at the earliest responsible moment.Again, although I created this thread, the state of the world is telling me a decision doesn’t need to be made quite yet.On Mar 27, 2023, at 5:29 AM, Benedict  wrote:I don’t know that TCM is a greater source of uncertainty. There is a degree of uncertainty about that :)I just think it’s better not to compound uncertainties, at least while it is not costly to avoid it.On 27 Mar 2023, at 08:27, Henrik Ingo  wrote:Seems like this thread is the more appropriate one for Accord/TCM discussionIMO the priority here should be:1. Release CEP-15 as part of 5.0, this year, with or without  CEP-21.2. Minimize work arising from porting between branches. (e.g. first onto CEP-21, then to trunk, or vice versa. But also then between 5.0 and trunk)3. Minimize work arising from temporary solutions that support goal #1If CEP-21 is the major source of uncertainty right now, then we should merge CEP-15 to trunk independently. If CEP-15 depending on CEP-21 just means an additional month (or two) delay, then that's fine and there's no need to do additional work just to get some preview release out earlier.henrikOn Sat, Mar 25, 2023 at 4:17 AM Caleb Rackliffe  wrote:I agree there’s little point in litigating right now, given test stability (or lack thereof) in cep-21-tcm. Eventually, though, I’m more or less aligned w/ David in the sense that getting ourselves planted on top of TCM as soon as possible is a good idea.On Mar 24, 2023, at 3:04 PM, Benedict  wrote:It’s not even clear such an effort would need to be different from that used by cep-21. The point is that there’s not much point litigating this now when we can keep our options open and better decouple the projects, since I don’t think we lose much this way.On 24 Mar 2023, at 19:58, David Capwell  wrote: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 clusterOn Mar 24, 2023, at 12:43 PM, Josh McKenzie  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 epochsIf 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  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 epochsDo 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/2227It wasn't too terrible, and I was actually able to get the main CQL-based Accord tests working as long as I disabled automatic forwardi

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[Benedict]

I don’t know that TCM is a greater source of uncertainty. There is a degree of uncertainty about that :)I just think it’s better not to compound uncertainties, at least while it is not costly to avoid it.On 27 Mar 2023, at 08:27, Henrik Ingo  wrote:Seems like this thread is the more appropriate one for Accord/TCM discussionIMO the priority here should be:1. Release CEP-15 as part of 5.0, this year, with or without  CEP-21.2. Minimize work arising from porting between branches. (e.g. first onto CEP-21, then to trunk, or vice versa. But also then between 5.0 and trunk)3. Minimize work arising from temporary solutions that support goal #1If CEP-21 is the major source of uncertainty right now, then we should merge CEP-15 to trunk independently. If CEP-15 depending on CEP-21 just means an additional month (or two) delay, then that's fine and there's no need to do additional work just to get some preview release out earlier.henrikOn Sat, Mar 25, 2023 at 4:17 AM Caleb Rackliffe  wrote:I agree there’s little point in litigating right now, given test stability (or lack thereof) in cep-21-tcm. Eventually, though, I’m more or less aligned w/ David in the sense that getting ourselves planted on top of TCM as soon as possible is a good idea.On Mar 24, 2023, at 3:04 PM, Benedict  wrote:It’s not even clear such an effort would need to be different from that used by cep-21. The point is that there’s not much point litigating this now when we can keep our options open and better decouple the projects, since I don’t think we lose much this way.On 24 Mar 2023, at 19:58, David Capwell  wrote: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 clusterOn Mar 24, 2023, at 12:43 PM, Josh McKenzie  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 epochsIf 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  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 epochsDo 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/2227It 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.In the meantime, I rebased cep-15-accord on trunk at commit 3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de. The option to finish the remaining bits of CASSANDRA-18196 and m

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[Henrik Ingo]

Seems like this thread is the more appropriate one for Accord/TCM discussion

IMO the priority here should be:

1. Release CEP-15 as part of 5.0, this year, with or without  CEP-21.
2. Minimize work arising from porting between branches. (e.g. first onto
CEP-21, then to trunk, or vice versa. But also then between 5.0 and trunk)
3. Minimize work arising from temporary solutions that support goal #1


If CEP-21 is the major source of uncertainty right now, then we should
merge CEP-15 to trunk independently. If CEP-15 depending on CEP-21 just
means an additional month (or two) delay, then that's fine and there's no
need to do additional work just to get some preview release out earlier.

henrik

On Sat, Mar 25, 2023 at 4:17 AM Caleb Rackliffe 
wrote:

> I agree there’s little point in litigating right now, given test stability
> (or lack thereof) in cep-21-tcm. Eventually, though, I’m more or less
> aligned w/ David in the sense that getting ourselves planted on top of TCM
> as soon as possible is a good idea.
>
> On Mar 24, 2023, at 3:04 PM, Benedict  wrote:
>
> 
> It’s not even clear such an effort would need to be different from that
> used by cep-21. The point is that there’s not much point litigating this
> now when we can keep our options open and better decouple the projects,
> since I don’t think we lose much this way.
>
> On 24 Mar 2023, at 19:58, David Capwell  wrote:
>
> 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  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  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
> .
>
> In the meantime, I rebased cep-15-accord on trunk at
> commit 3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de. The option to finish the
> remaining bits of CASSANDRA-18196
>  and merge w/o TCM
> is still availab

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[Caleb Rackliffe]

I agree there’s little point in litigating right now, given test stability (or lack thereof) in cep-21-tcm. Eventually, though, I’m more or less aligned w/ David in the sense that getting ourselves planted on top of TCM as soon as possible is a good idea.On Mar 24, 2023, at 3:04 PM, Benedict  wrote:It’s not even clear such an effort would need to be different from that used by cep-21. The point is that there’s not much point litigating this now when we can keep our options open and better decouple the projects, since I don’t think we lose much this way.On 24 Mar 2023, at 19:58, David Capwell  wrote: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 clusterOn Mar 24, 2023, at 12:43 PM, Josh McKenzie  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 epochsIf 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  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 epochsDo 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/2227It 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.In the meantime, I rebased cep-15-accord on trunk at commit 3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de. The option to finish the remaining bits of 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  wrote:making sure that joining and leaving nodes update some state via Paxos instead of via gossipWhat 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 almo

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[Caleb Rackliffe]

To be clear, I’m not suggesting that the CEP-7 branch be rebased on cep-21-tcm rather than trunk.On Mar 24, 2023, at 2:12 PM, Josh McKenzie  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 epochsDo 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/2227It 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.In the meantime, I rebased cep-15-accord on trunk at commit 3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de. The option to finish the remaining bits of 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  wrote:making sure that joining and leaving nodes update some state via Paxos instead of via gossipWhat 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  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  wrote:We've already talked a bit about how and when the current Accord feature branch should merge to trunk. Earlier today, the cep-21-tcm branch was created to house ongoing work on Transactional Metadata.Returning to 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 and 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 again.Any objections to this?--Henrik Ingoc. +358 40 569 7354 w. www.datastax.com      

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[Benedict]

It’s not even clear such an effort would need to be different from that used by cep-21. The point is that there’s not much point litigating this now when we can keep our options open and better decouple the projects, since I don’t think we lose much this way.On 24 Mar 2023, at 19:58, David Capwell  wrote: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 clusterOn Mar 24, 2023, at 12:43 PM, Josh McKenzie  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 epochsIf 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  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 epochsDo 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/2227It 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.In the meantime, I rebased cep-15-accord on trunk at commit 3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de. The option to finish the remaining bits of 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  wrote:making sure that joining and leaving nodes update some state via Paxos instead of via gossipWhat 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 th

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[David Capwell]

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  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  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 
 .
 
 In the meantime, I rebased cep-15-accord on trunk at commit 
 3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de. The option to finish the 
 remaining bits of 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 >>> > 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, 

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[Josh McKenzie]

> 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  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 
>>> .
>>> 
>>> In the meantime, I rebased cep-15-accord on trunk at commit 
>>> 3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de. The option to finish the 
>>> remaining bits of 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  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  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

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[David Capwell]

> 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  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 
>> .
>> 
>> In the meantime, I rebased cep-15-accord on trunk at commit 
>> 3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de. The option to finish the remaining 
>> bits of 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 > > 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 >>> > 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 >>> > wrote:
 We've already talked a bit 
 
  about how and when the current Accord feature branch should merge to 
 trunk. Earlier today, 

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[Benedict]

I agree, decoupling seems better to me. The fewer inter-effort dependencies, the less foot-treading.As Henrik mentioned, we don’t need a feature complete cep-15 to merge, as its integration is quite lightweight. We can leave some stuff to provide later, and depending on conditions at release time make a decision as to whether we release with cep-21, or with a minimal epoch facility (which would IMO not being a huge endeavour), or with it disabled altogether.On 24 Mar 2023, at 19:13, Josh McKenzie  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 epochsDo 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/2227It 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.In the meantime, I rebased cep-15-accord on trunk at commit 3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de. The option to finish the remaining bits of 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  wrote:making sure that joining and leaving nodes update some state via Paxos instead of via gossipWhat 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  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  wrote:We've already talked a bit about how and when the current Accord feature branch should merge to trunk. Earlier today, the cep-21-tcm branch was created to house ongoing work on Transactional Metadata.Returning to 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 and 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 rebas

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[Josh McKenzie]

> 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 
> .
> 
> In the meantime, I rebased cep-15-accord on trunk at commit 
> 3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de. The option to finish the remaining 
> bits of 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  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  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  
 wrote:
> We've already talked a bit 
> 
>  about how and when the current Accord feature branch should merge to 
> trunk. Earlier today, the cep-21-tcm branch was created 
>  to 
> house ongoing work on Transactional Metadata.
> 
> Returning to 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  
> and CASSANDRA-18320 
> 

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[Caleb Rackliffe]

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
.

In the meantime, I rebased cep-15-accord on trunk at
commit 3eb605b4db0fa6b1ab67b85724a9cfbf00aae7de. The option to finish the
remaining bits of 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  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  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 
> wrote:
>
> We've already talked a bit
> 
> about how and when the current Accord feature branch should merge to trunk.
> Earlier today, the cep-21-tcm branch was created
>  to
> house ongoing work on Transactional Metadata.
>
> Returning to 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 
>  and 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
>  again.
>
> Any objections to this?
>
>
>
> --
>
>
>
> *Henrik Ingo*
>
> *c*. +358 40 569 7354
>
> *w*. *www.datastax.com *
>
>   
> 
> 
>
>
>

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[Josh McKenzie]

> 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  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  
>> wrote:
>>> We've already talked a bit 
>>> 
>>>  about how and when the current Accord feature branch should merge to 
>>> trunk. Earlier today, the cep-21-tcm branch was created 
>>>  to house 
>>> ongoing work on Transactional Metadata.
>>> 
>>> Returning to 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  and 
>>> 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 
>>>  again.
>>> 
>>> Any objections to this?
>> 
>> 
>> --
>> 
>> 
>> 
>> 
>> *Henrik Ingo*
>> 
>> *c*. +358 40 569 7354 
>> 
>> *w*. _www.datastax.com_
>> 
>> __   __   
>> __   __ 
>> 
>> 

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[Benedict]

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  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  wrote:We've already talked a bit about how and when the current Accord feature branch should merge to trunk. Earlier today, the cep-21-tcm branch was created to house ongoing work on Transactional Metadata.Returning to 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 and 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 again.Any objections to this?
-- Henrik Ingoc. +358 40 569 7354 w. www.datastax.com      

Re: [DISCUSS] cep-15-accord, cep-21-tcm, and trunk

[Henrik Ingo]

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 
wrote:

> We've already talked a bit
> 
> about how and when the current Accord feature branch should merge to trunk.
> Earlier today, the cep-21-tcm branch was created
>  to
> house ongoing work on Transactional Metadata.
>
> Returning to 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 
>  and 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
>  again.
>
> Any objections to this?
>


-- 

Henrik Ingo

c. +358 40 569 7354

w. www.datastax.com