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 <m...@apache.org> 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 <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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
