> However it is used by a number of other features as a dependency such as > analytics, backup/restore, repair, metrics, and CDC It seems like a natural pressure relief valve for moving operations out of a core C* node that are well served out of process.
On Tue, Oct 1, 2024, at 4:52 PM, Jeremy Hanna wrote: > > The odd thing about the sidecar is that it wasn’t an end in itself. However > it is used by a number of other features as a dependency such as analytics, > backup/restore, repair, metrics, and CDC. > > I agree with Jeremiah about a 1.0 shippable version. Is there anything else > needed in the current sidecar that would hold it back from being that? > >> On Oct 1, 2024, at 12:22 PM, Jeremiah Jordan <jeremiah.jor...@gmail.com> >> wrote: >> >> I don’t really have an opinion on re-writing the existing one vs closing >> that and making a new one. >> But I do think we should have some CEP describing the "1.0 shippable >> version" of the side car that is being proposed, then it can have a VOTE >> thread, and there will be no issues voting the release meets the CEP once it >> is ready. >> >> -Jeremiah >> >> On Oct 1, 2024 at 7:58:41 AM, Josh McKenzie <jmcken...@apache.org> wrote: >>> >>>> CEP-1 is still completely relevant and we could send an update >>> CEP-1 feels really fat compared to all our other CEP's. When you need a >>> table to enumerate all the subsets of things you're going to do with >>> something so you can keep track of progress... it might be too large. :D >>> >>> If we think we can navigate that, I definitely won't stand in the way. But >>> given that the people actively working on it aren't the original authors >>> and the shepherd's inactive, ISTM a reboot would be cleaner. >>> >>> On Mon, Sep 30, 2024, at 8:36 PM, Dinesh Joshi wrote: >>>> CEP-1 is still completely relevant and we could send an update but as it >>>> stands right now we’ve made a ton of progress and would like to focus on >>>> getting to a release so it’s real for the community. >>>> >>>> On Mon, Sep 30, 2024 at 5:31 PM Patrick McFadin <pmcfa...@gmail.com> wrote: >>>>> There are two easy choices. >>>>> >>>>> 1 - Re-furbish CEP-1 and start a [DISCUSS] thread >>>>> 2 - Close out CEP-1 and Propose something fresh and start a [DISCUSS] >>>>> Thread on that. >>>>> >>>>> Do you think there is enough in CEP-1 to keep moving with or is it >>>>> completely wrong? >>>>> >>>>> Patrick >>>>> >>>>> On Mon, Sep 30, 2024 at 4:53 PM Francisco Guerrero <fran...@apache.org> >>>>> wrote: >>>>>> Hi folks, >>>>>> >>>>>> I feel I need to update the status of CEP-1 as it currently stands. >>>>>> For context, the Cassandra Sidecar project has had a steady flow of >>>>>> contributions in the past couple of years. And there is a steady stream >>>>>> of upcoming contributions, i.e live migration (CEP-40), CDC (CEP-44), >>>>>> and many others. However, I believe we need to address one issue >>>>>> with CEP-1; and that is its scope. >>>>>> The scope of CEP-1 is too broad, and I would like to propose either >>>>>> closing on CEP-1 or rescoping it. We have a Sidecar now, it's part of >>>>>> the foundation, and AFAIK we've pretty much satisfied the 2 goals of >>>>>> CEP-1 which are listed as "extensible and passes the curl test" and >>>>>> "provides basic but essential and useful functionality". >>>>>> CEP-1 was discussed and consensus was achieved in 2018 after >>>>>> a lot of discussion[4]. CEP-1 contributed to the foundation of the CEP >>>>>> process. Several JIRAs have been opened and active contribution is >>>>>> happening in the subproject. >>>>>> We are getting close to proposing the first release of Sidecar, pending >>>>>> some trivial fixes needed in the configuration and build >>>>>> processes[1][2][3]; >>>>>> as well as CASSANDRASC-141[5] which will bring authn/authz into Sidecar. >>>>>> Once >>>>>> we close on CASSANDRASC-141, Sidecar will be ready for the 1.0 release. >>>>>> Any new major feature to Sidecar would go through the regular CEP >>>>>> process. >>>>>> Cassandra’s Sidecar usage is not restricted to the Analytics library, >>>>>> however >>>>>> it does support this use case at the moment. I will not touch on vnode >>>>>> support in Cassandra Analytics as it deserves its own separate >>>>>> discussion. >>>>>> We're excited to invite you to a talk on Cassandra Sidecar at the >>>>>> Community >>>>>> Over Code next week. Join us as we explore the current features and share >>>>>> what’s on the horizon for Sidecar. >>>>>> >>>>>> Looking forward to hearing your thoughts on this proposal. >>>>>> Best, >>>>>> ⁃ Francisco >>>>>> [1] https://issues.apache.org/jira/browse/CASSANDRASC-120 >>>>>> [2] https://issues.apache.org/jira/browse/CASSANDRASC-121 >>>>>> [3] https://issues.apache.org/jira/browse/CASSANDRASC-122 >>>>>> [4] https://lists.apache.org/thread/xyg8n5hkt7xrfqv48k91tx1jwp0pvcpw >>>>>> [5] https://issues.apache.org/jira/browse/CASSANDRASC-141 >>>>>> >>>>>> >>>
