> 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
> 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
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
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.
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
+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
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
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
+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
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
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
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
> 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
>
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
14 matches
Mail list logo
