Re: Reaper as cassandra-admin

2018-08-28 Thread Mick Semb Wever


> the argument that something new should be written because an existing project 
> has tech debt, and we'll do it the right way this time, is a pretty common 
> software engineering mistake. The thing you’re replacing usually needs to 
> have some really serious problems to make it worth replacing.

 
Thanks for writing this Blake. I'm no fan of writing from scratch. Working with 
other people's code is the joy of open-source, imho.

Reaper is not a big project. None of its java files are large or complicated. 
This is not the C* codebase we're talking about. 

It comes with strict code style in place (which the build enforces), unit and 
integration tests. The tech debt that I think of first is removing stuff that 
we would no longer want to support if it were inside the Cassandra project. A 
number of recent refactorings  have proved it's an easy codebase to work with. 

It's also worth noting that Cassandra-4.x adoption is still some away, in which 
time Reaper will only continue to grow and gain users.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Reaper as cassandra-admin

2018-08-28 Thread Blake Eggleston
> 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.jo...@yahoo.com.INVALID 
(dinesh.jo...@yahoo.com.invalid) wrote:

On Tuesday, August 28, 2018, 2:52:03 PM PDT, Blake Eggleston 
 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 
(rtangir...@netflix.com.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   
 wrote:   

> > On Aug 27, 2018, at 5:36 PM, Jonathan Haddad  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-unsubscr...@cassandra.apache.org   
> For additional commands, e-mail: dev-h...@cassandra.apache.org   
>   
> 

Re: Reaper as cassandra-admin

2018-08-28 Thread dinesh.jo...@yahoo.com.INVALID
On Tuesday, August 28, 2018, 2:52:03 PM PDT, Blake Eggleston 
 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 
(rtangir...@netflix.com.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  
 wrote:  

> > On Aug 27, 2018, at 5:36 PM, Jonathan Haddad  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-unsubscr...@cassandra.apache.org  
> For additional commands, e-mail: dev-h...@cassandra.apache.org  
>  
>    

Re: Reaper as cassandra-admin

2018-08-28 Thread Sumanth Pasupuleti
IMO, I am glad to see there are at least three solutions here to address
repair and can be potential candidates for sidecar. As Joey pointed out,
all of them may not be great at everything they do, and to me, it makes
sense to "cherry pick" the best each product has, and build a good C*
sidecar.

Thanks,
Sumanth

On Tue, Aug 28, 2018 at 2:45 PM, Blake Eggleston 
wrote:

> I haven’t settled on a position yet (will have more time think about
> things after the 9/1 freeze), but I wanted to point out that the argument
> that something new should be written because an existing project has tech
> debt, and we'll do it the right way this time, is a pretty common software
> engineering mistake. The thing you’re replacing usually needs to have some
> really serious problems to make it worth replacing.
>
> I’m sure reaper will bring tech debt with it, but I doubt it's 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
> schedulers to it, and get people to actually use them than it would be to
> write something from scratch and build community confidence in it and get
> reaper users to switch.
>
> On August 28, 2018 at 1:40:59 PM, Roopa Tangirala 
> (rtangir...@netflix.com.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
>  wrote:
>
> > > On Aug 27, 2018, at 5:36 PM, Jonathan Haddad 
> 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-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>


Re: Reaper as cassandra-admin

2018-08-28 Thread Blake Eggleston
I haven’t settled on a position yet (will have more time think about things 
after the 9/1 freeze), but I wanted to point out that the argument that 
something new should be written because an existing project has tech debt, and 
we'll do it the right way this time, is a pretty common software engineering 
mistake. The thing you’re replacing usually needs to have some really serious 
problems to make it worth replacing.

I’m sure reaper will bring tech debt with it, but I doubt it's 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 schedulers to 
it, and get people to actually use them than it would be to write something 
from scratch and build community confidence in it and get reaper users to 
switch.

On August 28, 2018 at 1:40:59 PM, Roopa Tangirala 
(rtangir...@netflix.com.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  
 wrote:  

> > On Aug 27, 2018, at 5:36 PM, Jonathan Haddad  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-unsubscr...@cassandra.apache.org  
> For additional commands, e-mail: dev-h...@cassandra.apache.org  
>  
>  


Re: Supporting multiple JDKs

2018-08-28 Thread Jeff Jirsa
+1 from me on both points below 

-- 
Jeff Jirsa


> On Aug 28, 2018, at 1:40 PM, Sumanth Pasupuleti 
>  wrote:
> 
> Correct me if I am wrong, but I see the following consensus so far, on the
> proposal.
> 
> C* 2.2
> AnimalSniffer
> Use AnimalSniffer for compile-time feedback on JDK 1.7 compatibility -
> complete consensus so far
> Circle CI Builds
> In addition to existing JDK 1.8 support, build against JDK 1.7, and
> [optionally] run unit tests and DTests against JDK 1.7 - Dinesh and
> Sumanth +1 so far. Mick - I am not sure if you are +0 or -1 on this.
> 
> C* 4.0
> Circle CI Builds
> In addition to existing JDK 1.8 support, build against JDK 11 and
> [optionally] run unit tests and DTests against JDK 11. - complete consensus
> so far
> 
> If anyone has any further feedback, please comment.
> 
> Thanks,
> Sumanth
> 
> On Fri, Aug 24, 2018 at 7:27 AM Sumanth Pasupuleti
>  wrote:
> 
>>> I'm still a bit confused as to what's the benefit in compiling with
>> jdk1.7 and then testing with jdk1.7 or jdk1.8
>> I meant two separate workflows for each JDK i.e.
>> Workflow1: Build against jdk1.7, and optionally run UTs and Dtests against
>> 1.7
>> Workflow2: Build against jdk1.8, and run UTs and DTests against 1.8.
>> 
>>> If you find breakages here that otherwise don't exist when it's compiled
>> with jdk1.8 then that's just false-positives. As well as generally wasting
>> CI resources.
>> If we find breakages in workflow1, and not in workflow 2, how would they be
>> false positives? we will need to then look into whats causing breakages
>> with 1.7, isn't it?
>> 
>> Thanks,
>> Sumanth
>> 
>> On Thu, Aug 23, 2018 at 7:59 PM, Mick Semb Wever  wrote:
>> 
 However, in addition to using such a
 tool, I believe, when we make a release, we should build against the
>>> actual
 JDKs we support (that way, we are not making a release just based on
>> the
 result of an external tool), and we should be able to optionally run
>> UTs
 and DTests against the JDK  (i.e. Java7 and Java8 for C* 2.2).
>>> 
>>> 
>>> I'm still a bit confused as to what's the benefit in compiling with
>> jdk1.7
>>> and then testing with jdk1.7 or jdk1.8
>>> 
>>> If you find breakages here that otherwise don't exist when it's compiled
>>> with jdk1.8 then that's just false-positives. As well as generally
>> wasting
>>> CI resources.
>>> 
>>> Either way, there's not much point discussing this as Cassandra-2.1 is
>>> about EOL, and Cassandra-4.0 is stuck with a very specific compile.
>>> 
>>> -
>>> 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



Re: Supporting multiple JDKs

2018-08-28 Thread Sumanth Pasupuleti
Correct me if I am wrong, but I see the following consensus so far, on the
proposal.

C* 2.2
AnimalSniffer
Use AnimalSniffer for compile-time feedback on JDK 1.7 compatibility -
complete consensus so far
Circle CI Builds
In addition to existing JDK 1.8 support, build against JDK 1.7, and
[optionally] run unit tests and DTests against JDK 1.7 - Dinesh and
Sumanth +1 so far. Mick - I am not sure if you are +0 or -1 on this.

C* 4.0
Circle CI Builds
In addition to existing JDK 1.8 support, build against JDK 11 and
[optionally] run unit tests and DTests against JDK 11. - complete consensus
so far

If anyone has any further feedback, please comment.

Thanks,
Sumanth

On Fri, Aug 24, 2018 at 7:27 AM Sumanth Pasupuleti
 wrote:

> > I'm still a bit confused as to what's the benefit in compiling with
> jdk1.7 and then testing with jdk1.7 or jdk1.8
> I meant two separate workflows for each JDK i.e.
> Workflow1: Build against jdk1.7, and optionally run UTs and Dtests against
> 1.7
> Workflow2: Build against jdk1.8, and run UTs and DTests against 1.8.
>
> > If you find breakages here that otherwise don't exist when it's compiled
> with jdk1.8 then that's just false-positives. As well as generally wasting
> CI resources.
> If we find breakages in workflow1, and not in workflow 2, how would they be
> false positives? we will need to then look into whats causing breakages
> with 1.7, isn't it?
>
> Thanks,
> Sumanth
>
> On Thu, Aug 23, 2018 at 7:59 PM, Mick Semb Wever  wrote:
>
> > > However, in addition to using such a
> > > tool, I believe, when we make a release, we should build against the
> > actual
> > > JDKs we support (that way, we are not making a release just based on
> the
> > > result of an external tool), and we should be able to optionally run
> UTs
> > > and DTests against the JDK  (i.e. Java7 and Java8 for C* 2.2).
> >
> >
> > I'm still a bit confused as to what's the benefit in compiling with
> jdk1.7
> > and then testing with jdk1.7 or jdk1.8
> >
> > If you find breakages here that otherwise don't exist when it's compiled
> > with jdk1.8 then that's just false-positives. As well as generally
> wasting
> > CI resources.
> >
> > Either way, there's not much point discussing this as Cassandra-2.1 is
> > about EOL, and Cassandra-4.0 is stuck with a very specific compile.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>


Re: Reaper as cassandra-admin

2018-08-28 Thread Roopa Tangirala
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
 wrote:

> > On Aug 27, 2018, at 5:36 PM, Jonathan Haddad  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-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: Yet another repair solution

2018-08-28 Thread Roopa
+1 interested in seeing and understanding another repair solution. 

> On Aug 28, 2018, at 1:03 PM, Joseph Lynch  wrote:
> 
> I'm pretty interested in seeing and understanding your solution! When we
> started on CASSANDRA-14346 reading your design documents and plan you
> sketched out in CASSANDRA-10070 were really helpful in improving our
> design. I'm particularly interested in how the Scheduler/Job/Task APIs
> turned out (we're working on something similar internally and would love to
> compare notes and figure out the best way to implement that kind of
> abstraction)?
> 
> -Joey
> 
> 
> On Tue, Aug 28, 2018 at 6:34 AM Marcus Olsson 
> wrote:
> 
>> Hi,
>> 
>> With the risk of stirring the repair/side-car topic  even further I'd just
>> like to mention that we have recently gotten approval to contribute our
>> repair management side-car solution.
>> It's based on the proposal in
>> https://issues.apache.org/jira/browse/CASSANDRA-10070 as a standalone
>> application sitting next to each instance.
>> With the recent discussions in mind I'd just like to hear the thoughts
>> from the community on this before we put in the effort of bringing our
>> solution into open source.
>> 
>> Would there be an interest of having yet another repair solution in the
>> discussion?
>> 
>> Best Regards
>> Marcus Olsson
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Yet another repair solution

2018-08-28 Thread Joseph Lynch
I'm pretty interested in seeing and understanding your solution! When we
started on CASSANDRA-14346 reading your design documents and plan you
sketched out in CASSANDRA-10070 were really helpful in improving our
design. I'm particularly interested in how the Scheduler/Job/Task APIs
turned out (we're working on something similar internally and would love to
compare notes and figure out the best way to implement that kind of
abstraction)?

-Joey


On Tue, Aug 28, 2018 at 6:34 AM Marcus Olsson 
wrote:

> Hi,
>
> With the risk of stirring the repair/side-car topic  even further I'd just
> like to mention that we have recently gotten approval to contribute our
> repair management side-car solution.
> It's based on the proposal in
> https://issues.apache.org/jira/browse/CASSANDRA-10070 as a standalone
> application sitting next to each instance.
> With the recent discussions in mind I'd just like to hear the thoughts
> from the community on this before we put in the effort of bringing our
> solution into open source.
>
> Would there be an interest of having yet another repair solution in the
> discussion?
>
> Best Regards
> Marcus Olsson
>


Re: Reaper as cassandra-admin

2018-08-28 Thread Joseph Lynch
I and the rest of the Netflix Cassandra team share Dinesh's concerns. I was
excited to work on this project precisely because we were taking only the
best designs, techniques, and functionality out of the community sidecars
such as Priam, Reaper, and any other community tool and building the
simplest possible tool into Cassandra that could deliver the maximum value
to our users with the minimal amount of technical debt. For example, a
distributed, shared nothing architecture that communicates only through
state transitions in Cassandra data itself seems to be the most robust and
secure architecture (and indeed Reaper appears to be working towards
refactoring towards that).  Fundamental architecture is, in my experience,
very hard to refactor, and often starting fresh with the lessons learned
from the N previous iterations is the faster way to build real value. For
example, Reaper was built to be a repair tool, it is baked into the core
abstractions. It sounds like the community needs something more like a
distributed task execution engine which is fully pluggable (plugin whatever
ops task you want) and operates scheduled, oneshot, and daemon tasks.

What if we started with a basic framework as proposed in CASSANDRA-14395,
maybe add a pluggable execution engine as the first few commits and then
various community members can contribute plugins/modules that add various
functionality such as repair, backup, distributed restarts, upgrades,
etc..?  We would be striving very hard not to reinvent the wheel, rather we
would want to learn from previous iterations, keep what works well and
leave the rest.

Regarding Priam, we could offer to donate it but I think that the community
shouldn't accept it because it is full of years of technical debt and
decisions made by Netflix for Netflix. For example Priam currently has four
different backup solutions (three used in production, the latest not used
in production) that we have implemented over the years, and only the latest
one that is not yet in production should be contributed to the official
sidecar. The latest iteration is similar to the architecture of
https://github.com/hashbrowncipher/cassandra-mirror which is capable of per
minute, point in time backups; no previous iteration is capable of this.
Yes the earlier versions are "battle hardened" but we know those
architectures have fundamental flaws, are overly expensive, or simply won't
scale to the next 10x requirement. We have learned from those previous
iterations and are creating the next iteration that will scale another
order of magnitude. I also wouldn’t want to burden reviewers with looking
at the first three implementations or building the mental model all at once
of how Priam works end to end.

Practically speaking, I think it's much more logistically difficult to
accept one of the sidecar projects as is than building a new one
incrementally. The existing sidecars have dependencies that have to be
vetted, technical debt that must be trimmed, tens of thousands of lines of
code that have to be reviewed, and even if the community wants to make
changes those changes might be prohibitively difficult as the underlying
architecture has solidified.

Furthermore, all of these tools were designed without the notion that they
were shipping with Cassandra, which precluded them from being capable of
next generation features like removing compaction entirely from the live
request-response path into a separate process that can be limited with e.g.
cgroups to ensure isolation. Also they have supported many versions of
Cassandra over the years and therefore have layers of indirection and
abstraction added simply for dealing with various different APIs and
versions (I personally think the official sidecar should branch with
Cassandra and support current plus previous versions of Cassandra just like
the server does).

I hope that we decide as a community to put all the options on the table in
the open, learn from all of them, and pursue a solution that takes the best
from all the solutions and is unencumbered by historical decisions.

-Joey


Re: Yet another repair solution

2018-08-28 Thread Jonathan Haddad
I'm also very interested.


On Tue, Aug 28, 2018 at 8:47 AM Dinesh Joshi 
wrote:

> > On Aug 28, 2018, at 6:33 AM, Marcus Olsson 
> wrote:
> >
> > Hi,
> >
> > With the risk of stirring the repair/side-car topic  even further I'd
> just like to mention that we have recently gotten approval to contribute
> our repair management side-car solution.
> > It's based on the proposal in
> https://issues.apache.org/jira/browse/CASSANDRA-10070 as a standalone
> application sitting next to each instance.
> > With the recent discussions in mind I'd just like to hear the thoughts
> from the community on this before we put in the effort of bringing our
> solution into open source.
> >
> > Would there be an interest of having yet another repair solution in the
> discussion?
>
> I personally think looking at multiple options is important. So yes, it
> would be interesting to see your solution.
>
> Dinesh
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade


Re: Yet another repair solution

2018-08-28 Thread Dinesh Joshi
> On Aug 28, 2018, at 6:33 AM, Marcus Olsson  wrote:
> 
> Hi,
> 
> With the risk of stirring the repair/side-car topic  even further I'd just 
> like to mention that we have recently gotten approval to contribute our 
> repair management side-car solution.
> It's based on the proposal in 
> https://issues.apache.org/jira/browse/CASSANDRA-10070 as a standalone 
> application sitting next to each instance.
> With the recent discussions in mind I'd just like to hear the thoughts from 
> the community on this before we put in the effort of bringing our solution 
> into open source.
> 
> Would there be an interest of having yet another repair solution in the 
> discussion?

I personally think looking at multiple options is important. So yes, it would 
be interesting to see your solution.

Dinesh

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Yet another repair solution

2018-08-28 Thread Marcus Olsson
Hi,

With the risk of stirring the repair/side-car topic  even further I'd just like 
to mention that we have recently gotten approval to contribute our repair 
management side-car solution.
It's based on the proposal in 
https://issues.apache.org/jira/browse/CASSANDRA-10070 as a standalone 
application sitting next to each instance.
With the recent discussions in mind I'd just like to hear the thoughts from the 
community on this before we put in the effort of bringing our solution into 
open source.

Would there be an interest of having yet another repair solution in the 
discussion?

Best Regards
Marcus Olsson