As someone who has done a lot of work trying to make repair stable, I approve of this message ^_^
More than glad to help mentor this work > On Jul 24, 2023, at 6:29 PM, Jaydeep Chovatia <chovatia.jayd...@gmail.com> > wrote: > > 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 > <mailto: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. >> https://issues.apache.org/jira/browse/CASSANDRA-18555 >> 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 <mailto: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
