Re: Proposing an Apache Cassandra Management process

wrote: >> > >> >> > >> Thanks for starting this, Mick. I will flesh it out. >> > >> Dinesh >> > >> >> > >>On Sunday, October 21, 2018, 1:52:10 AM PDT, Mick Semb Wever < >> > m...@apache.org> wrote: >

Re: Proposing an Apache Cassandra Management process

> > >> Thanks for starting this, Mick. I will flesh it out. > > >> Dinesh > > >> > > >> On Sunday, October 21, 2018, 1:52:10 AM PDT, Mick Semb Wever < > > m...@apache.org> wrote: > > >> > > >> > > >>> But

Re: Proposing an Apache Cassandra Management process

gt; > >>> But I'll try to put together a strawman proposal for the doc(s) over > the > >>> weekend. > >> > >> I've thrown something quickly together here: > >> - > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201 >

Re: Proposing an Apache Cassandra Management process

:10 AM PDT, Mick Semb Wever >> wrote:  >> >> >>> But I'll try to put together a strawman proposal for the doc(s) over the >>> weekend. >> >> I've thrown something quickly together here: >> - https://cwiki.apache.org/confluence/pages

Re: Proposing an Apache Cassandra Management process

> I've thrown something quickly together here: >> - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201 >> - >> https://cwiki.apache.org/confluence/display/CASSANDRA/CIP-1%3A+Proposing+an+Apache+Cassandra+Management+process >> >> The former is a blatant

Re: Proposing an Apache Cassandra Management process

> > >>> But I'll try to put together a strawman proposal for the doc(s) over the > >>> weekend. > >> > >> > >> I've thrown something quickly together here: > >> - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=9

Re: Proposing an Apache Cassandra Management process

, Mick Semb Wever >> wrote: >> >> >>> But I'll try to put together a strawman proposal for the doc(s) over the >>> weekend. >> >> >> I've thrown something quickly together here: >> - https://cwiki.apache.org/confluence/pages/viewpa

Re: Proposing an Apache Cassandra Management process

ge.action?pageId=95652201 > - > https://cwiki.apache.org/confluence/display/CASSANDRA/CIP-1%3A+Proposing+an+Apache+Cassandra+Management+process > > The former is a blatant rip-off from the Kafka and Spark design proposal > pages that Dinesh previously mentioned. I'd hoped to do

Re: Proposing an Apache Cassandra Management process

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201 - https://cwiki.apache.org/confluence/display/CASSANDRA/CIP-1%3A+Proposing+an+Apache+Cassandra+Management+process The former is a blatant rip-off from the Kafka and Spark design proposal pages that Dinesh previously mentioned. I'd

Re: Proposing an Apache Cassandra Management process

posing+an+Apache+Cassandra+Management+process The former is a blatant rip-off from the Kafka and Spark design proposal pages that Dinesh previously mentioned. I'd hoped to do more of an analysis of the existing C* habits and precedence on design proposals (implicit in jira tickets), but

Re: Proposing an Apache Cassandra Management process

> Can you share the link to cwiki if you have started it ? > I haven't. But I'll try to put together a strawman proposal for the doc(s) over the weekend. Regards, Mick - To unsubscribe, e-mail:

Re: Proposing an Apache Cassandra Management process

I too have built a framework over the last year similar to what cstar does but for our purposes at smartthings. The intention is to OSS it, but it needs a round of polish, since it really is more of a utility toolbox for our small cassandra group. It relies on ssh heavily and performing work on

Re: Proposing an Apache Cassandra Management process

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

Re: Proposing an Apache Cassandra Management process

Hi Mick, Any other feedback? Thanks, Sankalp On Sun, Sep 30, 2018 at 8:54 AM Sankalp Kohli wrote: > Thank you for the feedback. There are lot of advantages of doing this in > Apache and you can read the thread to find more. The main one is to not > divide the energy between

Re: Proposing an Apache Cassandra Management process

Thank you for the feedback. There are lot of advantages of doing this in Apache and you can read the thread to find more. The main one is to not divide the energy between different tools. Also we will not be reinventing the wheel as I think this project can still get donations along the way.

Re: Proposing an Apache Cassandra Management process

Perfection is the enemy of the good enough. All if not most informed open source users understand that the tar they are downloading is “unsupported.” Most of the blog posts people read or the documentation they have is in place of tools. Open source software let alone Tooling even a nascent

Re: Proposing an Apache Cassandra Management process

Thanks Dinesh for looking at the tools and thanks Mick for listing them down. Based on Dinesh response, is it accurate to say that for bulk functionality, we have evaluated the tools listed by the community? If anything is missed we should discuss it as we want to make sure we looked at all

Re: Proposing an Apache Cassandra Management process

> On Sep 29, 2018, at 12:31 PM, Rahul Singh > wrote: > > 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. So there isn't a way to make it any better? You would prefer using an unsupported tool

Re: Proposing an Apache Cassandra Management process

Mick, I think there is someone who’s maintaining CTOP now.. I added it to my admin/monitoring list on https://github.com/Anant/awesome-cassandra Rahul On Sep 29, 2018, 3:20 PM -0400, Dinesh Joshi , wrote: > > On Sep 27, 2018, at 7:35 PM, Mick Semb Wever wrote: > > > > Reaper, > > I have

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

Re: Proposing an Apache Cassandra Management process

> On Sep 27, 2018, at 7:35 PM, Mick Semb Wever 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

Re: Proposing an Apache Cassandra Management process

> Mick - could you enumerate the list of tools you mentioned earlier? Dinesh, quickly the following come to mind… Reaper, Priam, Marcus Olsson's offering, CStar, OpsCenter. Then there's a host of command line tools like: ic-tools, ctop (was awesome, but is it maintained anymore?),

Re: Proposing an Apache Cassandra Management process

*bump* Mick - could you enumerate the list of tools you mentioned earlier? Dinesh On Sunday, September 23, 2018, 6:22:48 PM PDT, Dinesh Joshi wrote: Hi Mick, Thanks for the feedback. Please find my clarifications inline. > There's also been suggestions to take a step away from any

Re: Proposing an Apache Cassandra Management process

Hi Mick, Thanks for the feedback. Please find my clarifications inline. > There's also been suggestions to take a step away from any focus on code and > go back to documentation and brainstorming. I appreciate the work already > done in the gdoc, but there's a lot left to the imagination (or

Re: Proposing an Apache Cassandra Management process

Dinesh, > Most of the discussion and work was done off the mailing list - there's a > big risk involved when folks disappear for months at a time and resurface > with big pile of code plus an agenda that you failed to loop everyone in > on. Given all the discussions that have been had offline

Re: Proposing an Apache Cassandra Management process

I think this feature is important to the community and I don’t want to stifle that but if committers/contributors are working on the management process instead of testing 4.0 it takes away from it regardless of where the code lives. Waiting to merge until after 4.0, at a minimum, would benefit the

Re: Proposing an Apache Cassandra Management process

This is not part of core database and a separate repo and so my impression is that this can continue to make progress. Also we can always make progress and not merge it till freeze is lifted. Open to ideas/suggestions if someone thinks otherwise. > On Sep 22, 2018, at 03:13, kurt greaves

Re: Proposing an Apache Cassandra Management process

Is this something we're moving ahead with despite the feature freeze? On Sat, 22 Sep 2018 at 08:32, dinesh.jo...@yahoo.com.INVALID wrote: > I have created a sub-task - CASSANDRA-14783. Could we get some feedback > before we begin implementing anything? > > Dinesh > > On Thursday, September

Re: Proposing an Apache Cassandra Management process

I have created a sub-task - CASSANDRA-14783. Could we get some feedback before we begin implementing anything? Dinesh On Thursday, September 20, 2018, 11:22:33 PM PDT, Dinesh Joshi wrote: I have updated the doc with a short paragraph providing the clarification. Sankalp's

Re: Proposing an Apache Cassandra Management process

I have updated the doc with a short paragraph providing the clarification. Sankalp's suggestion is already part of the doc. If there aren't further objections could we move this discussion over to the jira (CASSANDRA-14395)? Dinesh > On Sep 18, 2018, at 10:31 AM, sankalp kohli wrote: > > How

Re: Proposing an Apache Cassandra Management process

How about we start with a few basic features in side car. How about starting with this 1. Bulk nodetool commands: User can curl any sidecar and be able to run a nodetool command in bulk across the cluster. :/bulk/nodetool/tablestats?arg0=keyspace_name.table_name= And later 2: Health checks. On

Re: Proposing an Apache Cassandra Management process

I will update the document to add that point. The document did not mean to serve as a design or architectural document but rather something that would spark a discussion on the idea. Dinesh On Thursday, September 13, 2018, 10:59:34 AM PDT, Jonathan Haddad wrote: Most of the

Re: Proposing an Apache Cassandra Management process

Most of the discussion and work was done off the mailing list - there's a big risk involved when folks disappear for months at a time and resurface with big pile of code plus an agenda that you failed to loop everyone in on. In addition, by your own words the design document didn't accurately

Re: Proposing an Apache Cassandra Management process

I have a few clarifications - The scope of the management process is not to simply run repair scheduling. Repair scheduling is one of the many features we could implement or adopt from existing sources. So could we please split the Management Process discussion and the repair scheduling? After

Re: Proposing an Apache Cassandra Management process

Reading through the history Sankalp posted (I think it was originally posted by Joey?), I think part of the problem we’re having here is that we’re trying to solve at least 3 problems with a single solution. Also, I don’t think everyone has the same goals in mind. The issues we’re trying to

Re: Proposing an Apache Cassandra Management process

(Using this thread and not the vote thread intentionally) For folks talking about vote being rushed. I would use the email from Joseph to show this is not rushed. There was no email on this thread for 4 months until I pinged. Dec 2016: Vinay worked with Jon and Alex to try to collaborate on

Re: Proposing an Apache Cassandra Management process

I agree with Jon and I think folks who are talking about tech debts in Reaper should elaborate with examples about these tech debts. Can we be more precise and list them down? I see it spread out over this long email thread!! On Sun, Sep 9, 2018 at 6:29 AM Elliott Sims wrote: > A big one to add

Re: Proposing an Apache Cassandra Management process

A big one to add to your list there, IMO as a user: * API for determining detailed repair state (and history?). Essentially, something beyond just "Is some sort of repair running?" so that tools like Reaper can parallelize better. On Sun, Sep 9, 2018 at 8:30 AM, Stefan Podkowinski wrote: >

Proposing an Apache Cassandra Management process

Does it have to be a single project with functionality provided by multiple plugins? Designing a plugin API at this point seems to be a bit early and comes with additional complexity around managing plugins in general. I was more thinking into the direction of: "what can we do to enable people to

Re: Proposing an Apache Cassandra Management process

It's interesting to me that someone would consider features of Reaper as "technical debt"... an odd way to word it. When we had proposed donating Reaper to the project, I had made the assumption people would realize the benefit of folding in a successful project. A working codebase with a large

Re: Proposing an Apache Cassandra Management process

Most of the discussions have been around whether we take some side car or do a cherry pick approach where we add a feature at a time to side car and use the best implementation. We have been discussing this first in April and now for several days. I think we all want some progress here. We will

Re: Proposing an Apache Cassandra Management process

On Fri, Sep 7, 2018 at 10:00 PM Blake Eggleston wrote: > > Right, I understand the arguments for starting a new project. I’m not saying > reaper is, technically speaking, the best place to start. The point I’m > trying to make is that the non-technical advantages of using an existing > project

Re: Proposing an Apache Cassandra Management process

Right, I understand the arguments for starting a new project. I’m not saying reaper is, technically speaking, the best place to start. The point I’m trying to make is that the non-technical advantages of using an existing project as a starting point may outweigh the technical benefits of a

Re: Proposing an Apache Cassandra Management process

The benefit is that it more closely matched the design doc, from 5 months ago, which is decidedly not about coordinating repair - it’s about a general purpose management tool, where repair is one of many proposed tasks

Re: Proposing an Apache Cassandra Management process

> What’s the benefit of doing it that way vs starting with reaper and > integrating the netflix scheduler? If reaper was just a really inappropriate > choice for the cassandra management process, I could see that being a better > approach, but I don’t think that’s the case. > The benefit, as

Re: Proposing an Apache Cassandra Management process

> I think we should accept the reaper project as is and make that cassandra management process 1.0, then integrate the Netflix scheduler (and other new features) into that. Integrating Netflix scheduler into reaper is mostly refactoring reaper code since they are different architectures. >

Re: Proposing an Apache Cassandra Management process

What’s the benefit of doing it that way vs starting with reaper and integrating the netflix scheduler? If reaper was just a really inappropriate choice for the cassandra management process, I could see that being a better approach, but I don’t think that’s the case. If our management process

Re: Proposing an Apache Cassandra Management process

> How can we continue moving this forward? > > Mick/Jon/TLP folks, is there a path here where we commit the > Netflix-provided management process, and you augment Reaper to work with it? > Is there a way we can make a larger umbrella that's modular that can > support either/both? There seems

Re: Proposing an Apache Cassandra Management process

I’d also like to see the end state you describe: reaper UI wrapping the Netflix management process with pluggable scheduling (either as is with reaper now, or using the Netflix scheduler), but I don’t think that means we need to start with reaper - if personally prefer the opposite direction,

Re: Proposing an Apache Cassandra Management process

On Fri, Sep 7, 2018 at 5:03 PM Jonathan Haddad wrote: > > We haven’t even defined any requirements for an admin tool. It’s hard to > make a case for anything without agreement on what we’re trying to build. > We were/are trying to sketch out scope/requirements in the #14395 and #14346 tickets as

Re: Proposing an Apache Cassandra Management process

I think we should accept the reaper project as is and make that cassandra management process 1.0, then integrate the netflix scheduler (and other new features) into that. The ultimate goal would be for the netflix scheduler to become the default repair scheduler, but I think using reaper as

Re: Proposing an Apache Cassandra Management process

We haven’t even defined any requirements for an admin tool. It’s hard to make a case for anything without agreement on what we’re trying to build. On Fri, Sep 7, 2018 at 7:17 PM Jeff Jirsa wrote: > How can we continue moving this forward? > > Mick/Jon/TLP folks, is there a path here where we

Re: Proposing an Apache Cassandra Management process

How can we continue moving this forward? Mick/Jon/TLP folks, is there a path here where we commit the Netflix-provided management process, and you augment Reaper to work with it? Is there a way we can make a larger umbrella that's modular that can support either/both? Does anyone believe there's

Re: Proposing an Apache Cassandra Management process

> > contributions should be evaluated based on the merit of code and their > > value add to the whole offering. I hope it does not matter whether that > > contribution comes from PMC member or a person who is not a committer. > > > I hope this goes without saying. Absolutely. Joseph and

Re: Proposing an Apache Cassandra Management process

On Mon, Aug 20, 2018 at 4:14 PM Roopa Tangirala wrote: > contributions should be evaluated based on the merit of code and their > value add to the whole offering. I hope it does not matter whether that > contribution comes from PMC member or a person who is not a committer. I hope this goes

Re: Proposing an Apache Cassandra Management process

+1 to everything that Joey articulated with emphasis on the fact that contributions should be evaluated based on the merit of code and their value add to the whole offering. I hope it does not matter whether that contribution comes from PMC member or a person who is not a committer. I would like

Re: Proposing an Apache Cassandra Management process

On Mon, Aug 20, 2018 at 4:23 AM Mick Semb Wever wrote: > > We are looking to contribute Reaper to the Cassandra project. > > Looking at the patch it's very similar in its base design already, but > Reaper does has a lot more to offer. We have all been working hard to move > it to also being a

Re: Proposing an Apache Cassandra Management process

> We are looking to contribute Reaper to the Cassandra project. > Just to clarify are you proposing contributing Reaper as a project via donation or you are planning on contributing the features of Reaper as patches to Cassandra? If the former how far along are you on the donation process? If the

Re: Proposing an Apache Cassandra Management process

Hi, Here is how I think we can make progress 1. Consensus is reached that we need side car as this thread is months old and I do not see any objections. I bumped it again and it is good to see it being active. 2. There is no consensus on new repo vs not. I will start a thread on it and lets

Re: Proposing an Apache Cassandra Management process

On Fri, 17 Aug 2018, at 14:27, Sankalp Kohli wrote: > I am bumping this thread because patch has landed for this with repair > functionality. We are looking to contribute Reaper to the Cassandra project. Looking at the patch it's very similar in its base design already, but Reaper does

Re: Proposing an Apache Cassandra Management process

That’s a good point. Let’s review the patch and when it is ready to commit, we can create the repo then. > On Aug 18, 2018, at 14:04, Stefan Podkowinski wrote: > > I think we do have some consensus that 1) we should give it a try to > have one or many side-car processes for non-essential

Re: Proposing an Apache Cassandra Management process

I think we do have some consensus that 1) we should give it a try to have one or many side-car processes for non-essential features, and that 2) they should be developed in a separate repo. I'm also open to the idea of accepting the proposed implementation as a possible side-car solution and

Re: Proposing an Apache Cassandra Management process

The thread for side car is months old and no one has opposed to it and hence someone developed it. I am not sure how else you get consensus. Regarding separate repo, how do we get consensus? > On Aug 18, 2018, at 05:19, Stefan Podkowinski wrote: > > I don't see that we have reached

Re: Proposing an Apache Cassandra Management process

I don't see that we have reached sufficient consensus on this yet. We've had a brief discussion about the pros and cons of in-tree cassandra vs separate ASF repo here, but let's not frame it like it's either or. From my perspective, there hasn't been any final decision yet whether the proposed

Re: Proposing an Apache Cassandra Management process

Thanks, Nate. I’ll create this request. Dinesh On Aug 17, 2018, at 5:09 PM, Nate McCall wrote: >> I'm not sure logistically how we get a new repo created and licensing and >> such, but if someone helps make it we can cut the patch against it >> > This is pretty straight forward. For

Re: Proposing an Apache Cassandra Management process

> I'm not sure logistically how we get a new repo created and licensing and > such, but if someone helps make it we can cut the patch against it > This is pretty straight forward. For precedent, see: https://issues.apache.org/jira/browse/CASSANDRA-13634 We currently have three repositories:

Re: Proposing an Apache Cassandra Management process

You can still use the same repo and go with different release cadence as Jeremiah mentioned, and yes, you can just pull the management sidecar, test, and rollout without rolling out the server. It looks like there are merits to both approaches, but it is going to come down to the appetite of the

Re: Proposing an Apache Cassandra Management process

Both approaches have merits. However the general consensus seems to be that we should put this in a separate repo and I agree. Dinesh On Friday, August 17, 2018, 10:46:04 AM PDT, Rahul Singh wrote: I understand the issues of managing different versions of two correlated components —

Re: Proposing an Apache Cassandra Management process

I understand the issues of managing different versions of two correlated components — but it is possible to create unit tests with core components of both. It takes more effort but it is possible. That being said, in my experience using Reaper and in the DataStax distribution , using OpsCenter

Re: Proposing an Apache Cassandra Management process

Speaking from experience (Reaper), I can say that developing a sidecar admin / repair tool out of tree that's compatible with multiple versions really isn't that big of a problem. We've been doing it for a while now. https://github.com/thelastpickle/cassandra-reaper/blob/master/.travis.yml On

Re: Proposing an Apache Cassandra Management process

While I would love to use a different build system (e.g. gradle) for the sidecar, I agree with Dinesh that a separate repo would make sidecar development much harder to verify, especially on the testing and compatibility front. As Jeremiah mentioned we can always choose later to release the

Re: Proposing an Apache Cassandra Management process

+1 in maintaining a separate project and release cycle for side car. We have been running side car in production for 6+ years and the rate of changes to the side car is much higher than to the actual data store. This will enable faster iteration needed for the side car and help folks roll out

Re: Proposing an Apache Cassandra Management process

Not sure why the two things being in the same repo means they need the same release process. You can always do interim releases of the management artifact between server releases, or even have completely decoupled releases. -Jeremiah > On Aug 17, 2018, at 10:52 AM, Blake Eggleston wrote: >

Re: Proposing an Apache Cassandra Management process

I'd be more in favor of making it a separate project, basically for all the reasons listed below. I'm assuming we'd want a management process to work across different versions, which will be more awkward if it's in tree. Even if that's not the case, keeping it in a different repo at this point

Re: Proposing an Apache Cassandra Management process

> On Aug 16, 2018, at 9:27 PM, Sankalp Kohli wrote: > > I am bumping this thread because patch has landed for this with repair > functionality. > > I have a following proposal for this which I can put in the JIRA or doc > > 1. We should see if we can keep this in a separate repo like Dtest.

Re: Proposing an Apache Cassandra Management process

I am bumping this thread because patch has landed for this with repair functionality. I have a following proposal for this which I can put in the JIRA or doc 1. We should see if we can keep this in a separate repo like Dtest. 2. It should have its own release process. 3. It should have

Re: Proposing an Apache Cassandra Management process

Thank you all for the feedback. Nate made a Google doc with the proposal in it and is linked off of the ticket. I will try to flesh it out as I gather your input. Dinesh On Wednesday, April 18, 2018, 5:12:49 PM PDT, kurt greaves wrote: For anyone looking Dinesh

Re: Proposing an Apache Cassandra Management process

For anyone looking Dinesh made a ticket already: CASSANDRA-14395 On 18 April 2018 at 18:14, Vinay Chella wrote: > This is a good initiative. We have advocated for and run a sidecar for the > past 5+ years, and

Re: Proposing an Apache Cassandra Management process

This is a good initiative. We have advocated for and run a sidecar for the past 5+ years, and we've learned and improved it a lot. We look forward to moving features from Priam (such as backup, HTTP -> JMX, etc) incrementally to this sidecar as they make sense. Thanks, Vinay Chella On Fri, Apr

Re: Proposing an Apache Cassandra Management process

On Thu, Apr 12, 2018 at 4:41 PM, Dinesh Joshi wrote: > Hey all - > With the uptick in discussion around Cassandra operability and after > discussing potential solutions with various members of the community, we > would like to propose the addition of a management

Re: Proposing an Apache Cassandra Management process

In my opinion this will be a great addition to the Cassandra and will take overall Cassandra project to next level. This will also improve user experience especially for new users. Jaydeep On Thu, Apr 12, 2018 at 2:42 PM Dinesh Joshi wrote: > Hey all - > With

Proposing an Apache Cassandra Management process

Hey all - With the uptick in discussion around Cassandra operability and after discussing potential solutions with various members of the community, we would like to propose the addition of a management process/sub-project into Apache Cassandra. The process would be responsible for common