>A targeted change that mitigates a large portion of the pain of a feature
I get the impression my emails are being answered without being read. I proposed an alternative approach that delivers the main benefits to more use cases with less additional logic to maintain. On 2026/10/06 22:38:11 Josh McKenzie wrote: > > trusting and migrating to new features (especially around consistency) will > > take time, and teams will want to continue using incremental repair in the > > interim. The CEP providing an opt-in flag for enabling this on > > anticompaction is a good way to prove out and validate the feature. > I second this Andy. Non-trivial features that have consistency implications > historically have had a really long ironing out period for bugs in this > ecosystem. A targeted change that mitigates a large portion of the pain of a > feature that's been a source of serious operational pain for... over a > decade? is non-controversial to me, even if we expect in 1-2 years to have > everyone on an entirely new implementation. That's .5-1.5 years of that pain > being mitigated on the conservative side, assuming things went slowly on this > CEP implementation, best-case on Mutation Tracking, and best-case on release > and adoption. > > I think we need to get more comfortable with allowing multiple versions of > things to co-exist (and actually starting to use our experimental flag in > earnest) in this project if we want to make controlled progress on things. > Big swings in software have high risk/reward, and hedging our bets by > improving our existing implementations is just good strategy. > > On Tue, Oct 6, 2026, at 5:51 PM, Andy Tolbert wrote: > > > > > Indeed. It is exceptionally hard to run k8s without ebs. Possible but > > > requires doing a lot of very unnatural things. > > > > Agreed, using Kubernetes without disaggregated storage is incredibly > > difficult and using local disks violates a lot of the value of Kubernetes. > > > > I want to make sure that it doesn't get lost that anticompaction is an > > incredibly real problem even with fast NVMEs that causes operational pain > > daily, which would be fantastic to address. > > > > If new features (Mutation Tracking) mitigate the need for anticompaction, > > that is great, but trusting and migrating to new features (especially > > around consistency) will take time, and teams will want to continue using > > incremental repair in the interim. The CEP providing an opt-in flag for > > enabling this on anticompaction is a good way to prove out and validate the > > feature. Aside from that the CEP also offers value in improving the > > partial-range sstable streaming path as well. > > > > Thanks, > > Andy > > > > > > On Tue, Oct 6, 2026, at 3:04 PM, Benedict Elliott Smith wrote: > > > Not recommended means we do not recommend it, and do not provide > > > guidance for deploying on it. If you believe we *should* recommend EBS > > > we can have that discussion. My view is that a lot of decisions in the > > > database make little sense in this deployment, and should be revisited > > > to support it as a first class deployment option - and somebody needs > > > to do that work. At minimum we need dedicated guidance before > > > considering it one of our supported deployments. > > > > > > Either way, while this was the motivation, the alternative option’s > > > downside is not really a problem on EBS, so it actually only > > > strengthens the case for pursuing it. > > > > > > > > > On 2026/10/06 19:46:42 Jeff Jirsa wrote: > > >> Indeed. It is exceptionally hard to run k8s without ebs. Possible but > > >> requires > > >> doing a lot of very unnatural things. > > >> > > >> > > >> > > >> Most of the planet is going towards containerized deployments for > > >> relatively > > >> obvious reasons. > > >> > > >> > > >> > > >> It’s not something we should actively discourage. > > >> > > >> > > >> > > >> > On Oct 6, 2026, at 12:32 PM, Jon Haddad <[email protected]> > > >> > wrote: > > >> > > > >> > > > >> > > >> > > > >> > > > >> > Agreed. Most teams I’ve worked with are on EBS. It’s significantly > > >> > cheaper > > >> > for denser storage. I’m running 15-20TB nodes. Ever since we merged > > >> > CASSANDRA-15452, its worked really well. > > >> > > > >> > > > >> > > > >> > > > >> > Anyone using k8s is probably using EBS. > > >> > > > >> > > > >> > > > >> > > > >> > On Tue, Oct 6, 2026 at 12:20 PM Jeff Jirsa > > >> > <[[email protected]](mailto:[email protected])> wrote: > > >> > > > >> > > > >> > > >> >> > > >> > > > >> > > On Oct 6, 2026, at 4:49 AM, Benedict > > >> > <[[email protected]](mailto:[email protected])> wrote: > > >> > > > > >> > > > > >> > >> > > >> > >> This feature primarily benefits a narrow and not recommended use > > >> > case > > >> > (EBS), and our roadmap expects to obsolete it. The first draft > > >> > increases the > > >> > core codebase size by around 1%, and more for later phases - this isn’t > > >> > small. > > >> > > > > >> > > Sorry, in my edits for brevity I lost the point I was making here. > > >> > Given > > >> > the narrower benefit and lifetime of the feature, and non-trivial > > >> > cost, we > > >> > should try to see if we have alternatives that yield a stronger > > >> > cost:benefit > > >> > ratio. > > >> > > > > >> > > FWIW, I think cheap partial range streaming is an independently > > >> > important > > >> > thing we want to achieve, that is of long term benefit to the project > > >> > - and > > >> > I am not opposed to these other improvements in principle either. > > >> > > > > >> > >> On 6 Oct 2026, at 11:14, Benedict Elliott Smith > > >> > <[[email protected]](mailto:[email protected])> wrote: > > >> > >> > > >> > >> Hi Chris, > > >> > >> > > >> > >>> I think you would agree that complexity alone is not a reason to > > >> > reject > > >> > a design. You described Accord as “likely the most complex thing we > > >> > have > > >> > ever merged to the project,” > > >> > >> > > >> > >> Yes, we are discussing cost:benefit. Many proposals are subject to > > >> > debate, and I am sure you will recall that Accord was by no means > > >> > exempted > > >> > from this. > > >> > >> > > >> > >> This feature primarily benefits a narrow and not recommended use > > >> > case > > >> > (EBS), and our roadmap expects to obsolete it. The first draft > > >> > increases the > > >> > core codebase size by around 1%, and more for later phases - this isn’t > > >> > small. > > >> > >>> > > >> > > > >> > It’s not that narrow, and I dont know that I’d agree about it being > > >> > not- > > >> > recommended (I personally put more than one company on it intentionally > > >> > despite the disk latency because of the cost and operational > > >> > simplicity) > > >> > > > >> > I’d bet most deployments of Cassandra are on disaggregated disks of > > >> > some > > >> > kind (ebs, ceph, azure premium disks, etc). > > >> > > > >> > Most local nvme offerings are ephemeral in cloud environments and much > > >> > harder to deal with operationally. > > >> > > >> > >
