To clarify the repair solution timing, the one we have listed in the article is not the recently developed one. We were hitting some high-priority production challenges back in early 2018, and to address that, we developed and rolled out the solution in production in just a few months. The timing-wise, the solution was developed and productized by Q3 2018, of course, continued to evolve thereafter. Usually, we explore the existing solutions we can leverage, but when we started our journey in early 2018, most of the solutions were based on sidecar solutions. There is nothing against the sidecar solution; it was just a pure business decision, and in that, we wanted to avoid the sidecar to avoid a dependency on the control plane. Every solution developed has its deep context, merits, and pros and cons; they are all great solutions!
An appeal to the community members is to think one more time about having repairs in the Open Source Cassandra itself. As mentioned in my previous email, any solution getting adopted is fine; the important aspect is to have a repair solution in the OSS Cassandra itself! Yours Faithfully, Jaydeep On Mon, Jul 24, 2023 at 3:46 PM Jaydeep Chovatia <chovatia.jayd...@gmail.com> wrote: > Hi German, > > The goal is always to backport our learnings back to the community. For > example, I have already successfully backported the following two > enhancements/bug fixes back to the Open Source Cassandra, which are > described in the article. I am already currently working on open-source a > few more enhancements mentioned in the article back to the open-source. > > 1. https://issues.apache.org/jira/browse/CASSANDRA-18555 > 2. https://issues.apache.org/jira/browse/CASSANDRA-13740 > > There is definitely heavy interest in having the repair solution inside > the Open Source Cassandra itself, very much like Compaction. As I write > this email, we are internally working on a one-pager proposal doc to all > the community members on having a repair inside the OSS Apache Cassandra > along with our private fork - I will share it soon. > > Generally, we are ok with any solution getting adopted (either Joey's > solution or our repair solution or any other solution). The primary > motivation is to have the repair embedded inside the open-source Cassandra > itself, so we can retire all various privately developed solutions > eventually :) > > I am also happy to help (drive conversation, discussion, etc.) in any way > to have a repair solution adopted inside Cassandra itself, please let me > know. Happy to help! > > Yours Faithfully, > Jaydeep > > On Mon, Jul 24, 2023 at 1:44 PM German Eichberger via dev < > dev@cassandra.apache.org> wrote: > >> All, >> >> We had a brief discussion in [2] about the Uber article [1] where they >> talk about having integrated repair into Cassandra and how great that is. I >> expressed my disappointment that they didn't work with the community on >> that (Uber, if you are listening time to make amends 🙂) and it turns out >> Joey already had the idea and wrote the code [3] - so I wanted to start a >> discussion to gauge interest and maybe how to revive that effort. >> >> Thanks, >> German >> >> [1] >> https://www.uber.com/blog/how-uber-optimized-cassandra-operations-at-scale/ >> [2] https://the-asf.slack.com/archives/CK23JSY2K/p1690225062383619 >> [3] https://issues.apache.org/jira/browse/CASSANDRA-14346 >> >
