Dinesh / Sankalp, My suggestion was to document the landscape in hope and an attempt to better understand the requirements possible to a side-car. It wasn't a suggestion to patchwork together everything. But rather as part of brainstorming, designing, and exercising an inclusive process to see what's been done and how it could have been done better.
A well designed side-car could also be a valuable fundamental to some of these third-party solutions, not just our own designs and ideals. Maybe, I hope, that's already obvious. It would be really fantastic to see more explorative documentation in confluence. Part of that can be to list up all these external tools, listing their goals, state, and how a side-car might help them. Reaching out to their maintainers to be involved in the process would be awesome too. I can start something in the cwiki (but i'm on vacation this week), I've also given you write-access Dinesh. > I also haven't seen a process to propose & discuss larger changes to > Cassandra. The Cassandra contribution[1] guide possibly needs to be updated. > Some communities have a process which facilitate things. See Kafka > Improvement Process[2], Spark Improvement Process[3]. Bringing this up was gold, imho. I would love to see something like this exist in the C* community (also in cwiki), and the side-car brainstorming and design used to test and flesh it out. regards, Mick On Sun, 30 Sep 2018, at 05:19, Dinesh Joshi wrote: > > On Sep 27, 2018, at 7:35 PM, Mick Semb Wever <m...@apache.org> wrote: > > > > Reaper, > > I have looked at this already. > > > Priam, > > I have looked at this already. > > > Marcus Olsson's offering, > > This isn't OSS. > > > CStar, > > I have looked at this already. > > > OpsCenter. > > Latest release is only compatible with DSE and not Apache Cassandra[1] > > > Then there's a host of command line tools like: > > ic-tools, > > ctop (was awesome, but is it maintained anymore?), > > tablesnap. > > These are interesting tools and I don't think they do what we're > interested in doing. > > > And maybe it's worth including the diy approach people take… > > pssh/dsh/clusterssh/mussh/fabric, etc > > What's the point? You can definitely add this to the website as helpful > documentation. > > The proposal in the original thread was to create something that is > supported by the Apache Cassandra project learning from the tooling > we've all built over the years. The fact that everyone has a sidecar or > their own internal tooling is an indicator that the project has room to > grow. It will certainly help this project be more user friendly (at > least for operators). > > I, as a user and a developer, do not want to use a patchwork of > disparate tools. Does anybody oppose this on technical grounds? If you > do, please help me understand why would you prefer using a patchwork of > tools vs something that is part of the Cassandra project? > > Thanks, > > Dinesh > > [1] https://docs.datastax.com/en/opscenter/6.0/opsc/opscPolicyChanges.html > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
