osdir.com


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

Re: Proposing an Apache Cassandra Management process


Hi Mick,
             Can you share the link to cwiki if you have started it ?

Thanks
Sankalp 

> On Oct 4, 2018, at 5:20 PM, Mick Semb Wever <mck@xxxxxxxxxx> wrote:
> 
> 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 <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
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx