osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposing an Apache Cassandra Management process


All of Apache is a patchwork of tools. All of Open Source is a patchwork of tools. All of Linux is a patchwork of tools.

What works, works.

If it wasn’t a patchwork, open source wouldn’t be what it is. Period.

OSS Cassandra can use all the help it can get — in terms of documentation, and tooling. Personally I think starting out with documenting it for people is a good start.

Then maybe if there’s a thought later, a “distribution” approach can be taken.

When you think about the application developer or administrator, they are different from who we are. They don’t give a shit about “patchwork” or perfection, they just care to get their job done and make shit happen.

Who cares if one tool is in Java, and another is in Kotlin, and another is a shell script that uses PSSH? Something that works is better than nothing.


On Sep 29, 2018, 3:20 PM -0400, Dinesh Joshi <dinesh.joshi@xxxxxxxxx.invalid>, wrote:
> > On Sep 27, 2018, at 7:35 PM, Mick Semb Wever <mck@xxxxxxxxxx> 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
>