Sure thing!

Up until now it has been running in an OSGi environment, so among other
things I'm working towards both OSGi and a standalone application.

It's designed to be tightly coupled with a single instance, where it
keeps track of the repair state and performs repair of tables for that
node only.
The current features include alarms, "pausing repairs", metrics,
dynamic scheduling and "pluggability" for each of them (as well as some
other components like connection management, lease management, etc).

The design is based on CASSANDRA-10070 with Cassandra (and LWT) as a
default backend for the lease management. It utilizes the repair
history from Cassandra to determine repair state of tables in order to
prioritize and schedule them. This also means that a manual "nodetool
repair" would be counted towards the repair state of the tables.

Best Regards
Marcus Olsson

On tor, 2018-08-30 at 07:55 -0700, Dinesh Joshi wrote:
> In the meanwhile, do you think you could highlight the features of
> your repair solution / sidecar?
> 
> Dinesh
> 
> > 
> > On Aug 30, 2018, at 4:57 AM, Marcus Olsson <marcus.olsson@ericsson.
> > com> wrote:
> > 
> > Great to see that there is an interest! As there currently are some
> > internal dependencies etc. in place there is still some work to be
> > done before we can publish it. I would expect this to take at least
> > a few weeks, to try set the correct expectations.
> > 
> > Best Regards
> > Marcus Olsson
> > 
> > On tis, 2018-08-28 at 23:18 -0700, Vinay Chella wrote:
> > I am excited to see that the community is working on solving the
> > critical
> > problems in C* operations (e.g., repair, backups etc.,) with
> > different
> > solutions. Of course, learnings from these systems are key to
> > designing the
> > robust solution which works for everyone.
> > 
> > 
> > Thanks,
> > Vinay Chella
> > 
> > 
> > On Tue, Aug 28, 2018 at 1:23 PM Roopa <rtangir...@netflix.com.inval
> > id<mailto:rtangir...@netflix.com.invalid>>
> > wrote:
> > 
> > 
> > +1 interested in seeing and understanding another repair solution.
> > 
> > 
> > On Aug 28, 2018, at 1:03 PM, Joseph Lynch <joe.e.ly...@gmail.com<ma
> > ilto:joe.e.ly...@gmail.com>> 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 <
> > marcus.ols...@ericsson.com<mailto:marcus.ols...@ericsson.com>>
> > 
> > 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<mailto
> > :dev-unsubscr...@cassandra.apache.org>
> > For additional commands, e-mail: dev-h...@cassandra.apache.org<mail
> > to:dev-h...@cassandra.apache.org>
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

Reply via email to