>* There is a branch that Jaydeep had been keeping in sync off of 4.1.6 ( https://github.com/apache/cassandra/pull/3367). I'm not sure how up to date it is but the last commit on the branch is Sep 21 2025.
This is up to date. A few folks have already been using this in production. >I agree with Scott and others that the implications around the auto_repair table-level property and the system_distributed tables that are added as part of CEP-37 should be thoroughly understood and vetted One of the practices we follow locally is to perform a two-step rollout: the first cut includes only schema changes, and the second includes the feature. That way, we can safely roll back the feature without worrying about backward compatibility. Jaydeep On Tue, Dec 2, 2025 at 10:23 PM Tolbert, Andy <[email protected]> wrote: > I'd be happy to see this, but I agree with Scott and others that the > implications around the auto_repair table-level property and the > system_distributed tables that are added as part of CEP-37 should be > thoroughly understood and vetted. > > I also wanted to note a few things about a possible backport: > > * There is a branch that Jaydeep had been keeping in sync off of 4.1.6 ( > https://github.com/apache/cassandra/pull/3367). I'm not sure how up to > date it is but the last commit on the branch is Sep 21 2025. > * As for "How far to backport", from previous discussions I know there has > been an appetite to backport this to 4.1, but I'd be curious what the > appetite would be for 4.0. I think if we backport it at all, we should be > aiming at least for 4.1 as a minimum. > * While the code in CEP-37 is rather isolated, maintaining it on 4.1+ > should hopefully not add too much burden to maintain; however, we are > benefitting from changes in 5.0 (CASSANDRA-20092) for simplifying getting > amount of bytes a token range covers in an SSTable, where the 4.1 > implementation makes some changes to BigTableScanner to get what we need ( > https://github.com/apache/cassandra/pull/3367/files#diff-e8c75699e007d2ac1f3563865ee5b3769bae24eee75936e27c1d5c603aabd4cc), > which are less optimal than the impl used on trunk (but maybe not enough to > matter?). > * Some API changes around TCM meant how we look up replicas in AutoRepair > are different in 4.1/5.0 vs trunk. > > Andy > > On Tue, Dec 2, 2025 at 2:35 PM Brandon Williams <[email protected]> wrote: > >> It still changes the schema hash in 4.0, yeah. >> >> Kind Regards, >> Brandon >> >> On Tue, Dec 2, 2025 at 2:34 PM Jeff Jirsa <[email protected]> wrote: >> > >> > Is it still the case (4.0, 4.1) where adding the table param changes >> the schema hash (including in the mixed mode during the first deploy), or >> is that a solved problem in 4.0+? >> > >> > >> > >> > >> > > On Dec 2, 2025, at 2:54 PM, Brandon Williams <[email protected]> >> wrote: >> > > >> > > Maybe I was too hasty with my vote, then. I know from experience that >> > > once table params or new system table properties are added, rolling >> > > back is generally not possible. That can perhaps be fixed in some way >> > > but nothing currently exists. >> > > >> > > Kind Regards, >> > > Brandon >> > > >> > > On Tue, Dec 2, 2025 at 1:49 PM C. Scott Andreas <[email protected]> >> wrote: >> > >> >> > >> The patch will need vetting for compatibility implications of >> upgrades from (e.g.,) 4.0 + CEP-37 to newer-versioned releases like Apache >> Cassandra 5.0.6 that don't have this change. >> > >> >> > >> Some sources of potential incompatibility (briefly scanned, not >> vetted) look like: >> > >> >> > >> – Table params: >> https://github.com/apache/cassandra/commit/6753fb49dcba6af6cccc02e62a5d425704d45b20#diff-44546e8ca2f2a8a986ec2b16f837b7526f2444e5fb2c6367abf35d8756fd0e51R578-R631 >> > >> – system_distributed generation bump: >> https://github.com/apache/cassandra/commit/6753fb49dcba6af6cccc02e62a5d425704d45b20#diff-68edc51628c3cf6a0e9dbcff0dd697e130b952e0f328699db5541a21300aa0b2R89-R104 >> > >> – System table: >> https://github.com/apache/cassandra/commit/6753fb49dcba6af6cccc02e62a5d425704d45b20#diff-68edc51628c3cf6a0e9dbcff0dd697e130b952e0f328699db5541a21300aa0b2R166 >> > >> >> > >> >> > >> On Dec 2, 2025, at 11:36 AM, Josh McKenzie <[email protected]> >> wrote: >> > >> >> > >> >> > >> In a couple prior discuss threads, the topic of backporting >> in-project repair scheduling (CEP-37) came up a few times and the consensus >> seemed to be that everyone was receptive to us backporting this feature to >> all GA branches. The goal of this thread is to focus on that and formalize >> discussion and consensus before a potential vote. >> > >> >> > >> Here's a link to the CEP-37: >> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-37%3A+Apache+Cassandra+Unified+Repair+Solution >> > >> >> > >> And a link to the JIRA for the impl: >> https://issues.apache.org/jira/browse/CASSANDRA-19918 >> > >> >> > >> And here's the PR: >> https://github.com/apache/cassandra/commit/6753fb49dcba6af6cccc02e62a5d425704d45b20 >> > >> >> > >> So: what do we think? >> > >> >> > >> I'm personally +1 on allowing this to be backported to 4.0, 4.1, and >> 5.0. >> > >> >> > >> ----- >> > >> Prior reading: >> > >> - Discussing potential of a backport branch: >> https://lists.apache.org/thread/xbxt21rttsqvhmh8ds9vs2cr7fx27w3k >> > >> - Discussing understanding fork motivations: >> https://lists.apache.org/thread/5nv1f4bng4nw5ofgh135k5pf2f6l6lgl >> > >> >> > >> >> > >> >
