git.net

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

Re: Reaper as cassandra-admin


> FTR nobody has called Reaper a "hopeless mess".

I didn't mean they did. I just meant that it's generally a bad idea to do a rewrite unless the thing being rewritten is a hopeless mess, which reaper probably isn't. I realize this isn't technically a rewrite since we're not talking about actually rewriting something that's part of the project, but a lot of the same reasoning applies to starting work on a new admin tool vs using reaper as a starting point. It's not a strictly technical decision either. The community of users and developers already established around reaper is also a consideration.
On August 28, 2018 at 3:53:02 PM, dinesh.joshi@xxxxxxxxx.INVALID (dinesh.joshi@xxxxxxxxx.invalid) wrote:

On Tuesday, August 28, 2018, 2:52:03 PM PDT, Blake Eggleston <beggleston@xxxxxxxxx> wrote:  
> I’m sure reaper will bring tech debt with it, but I doubt it's a hopeless mess.   
FTR nobody has called Reaper a "hopeless mess".  
> It would bring a relatively mature project as well as a community of users> and developers that the other options won’t. It’s probably a lot less work to > rework whatever shortcomings reaper has, add new-hotness repair  

You can bring in parts of a relatively mature project that minimize refactoring & changes that need to be made once imported. You can also bring in best parts of multiples projects without importing entire codebases.  
Dinesh  


On August 28, 2018 at 1:40:59 PM, Roopa Tangirala (rtangirala@xxxxxxxxxxx.invalid) wrote:  
I share Dinesh's concern too regarding tech debt with existing codebase.   
Its good we have multiple solutions for repairs which have been always   
painful in Cassandra. It would be great to see the community take the best   
pieces from the available solutions and roll it into the fresh side car   
which will help ease Cassandra's maintenance for lot of folks.   

My main concern with starting with an existing codebase is that it comes   
with tech debt. This is not specific to Reaper but to any codebase that is   
imported as a whole. This means future developers and patches have to work   
within the confines of the decisions that were already made. Practically   
speaking once a codebase is established there is inertia in making   
architectural changes and we're left dealing with technical debt.   



*Regards,*   

*Roopa Tangirala*   

Engineering Manager CDE   

*(408) 438-3156 - mobile*   






On Mon, Aug 27, 2018 at 10:49 PM Dinesh Joshi   
<dinesh.joshi@xxxxxxxxx.invalid> wrote:   

> > On Aug 27, 2018, at 5:36 PM, Jonathan Haddad <jon@xxxxxxxxxxxxx> wrote:   
> > We're hoping to get some feedback on our side if that's something people   
> > are interested in. We've gone back and forth privately on our own   
> > preferences, hopes, dreams, etc, but I feel like a public discussion   
> would   
> > be healthy at this point. Does anyone share the view of using Reaper as   
> a   
> > starting point? What concerns to people have?   
>   
>   
> I have briefly looked at the Reaper codebase but I am yet to analyze it   
> better to have a real, meaningful opinion.   
>   
> My main concern with starting with an existing codebase is that it comes   
> with tech debt. This is not specific to Reaper but to any codebase that is   
> imported as a whole. This means future developers and patches have to work   
> within the confines of the decisions that were already made. Practically   
> speaking once a codebase is established there is inertia in making   
> architectural changes and we're left dealing with technical debt.   
>   
> As it stands I am not against the idea of using Reaper's features and I   
> would very much like using mature code that has been tested. I would   
> however like to propose piece-mealing it into the codebase. This will give   
> the community a chance to review what is going in and possibly change some   
> of the design decisions upfront. This will also avoid a situation where we   
> have to make many breaking changes in the initial versions due to   
> refactoring.   
>   
> I would also like it if we could compare and contrast the functionality   
> with Priam or any other interesting sidecars that folks may want to call   
> out. In fact it would be great if we could bring in the best functionality   
> from multiple implementations.   
>   
> Dinesh   
> ---------------------------------------------------------------------   
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx   
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx   
>   
>