In [2] we suggested that the next step should be a CEP. I am happy to lend a hand to this effort as well.
Thanks Jaydeep and David - really appreciated. German ________________________________ From: David Capwell <dcapw...@apple.com> Sent: Tuesday, July 25, 2023 8:32 AM To: dev <dev@cassandra.apache.org> Cc: German Eichberger <german.eichber...@microsoft.com> Subject: [EXTERNAL] Re: [Discuss] Repair inside C* 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. 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<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
