Agreed here - combining effort and making things pluggable seems like a good
solution
--
Jeff Jirsa
On Aug 28, 2018, at 11:44 PM, Vinay Chella 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
2c: There's a lot to think about here, and as Blake already mentioned most
people don't have time to dedicate a lot of thought to this at the moment.
There appear to be a lot of voices missing from the discussion, and I think
it's pretty clear this isn't super tied to the freeze, so maybe we
> 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
> 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
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
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
> 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
I’d be interested in contributing as well. I’ve been working on a skew review /
diagnostics tool which feeds off of cfstats/tbstats data (from TXT output to
CSV to conditionally formatted excel ) and am starting to store data in C* and
wrap a React based grid on it.
I have backlogged forking
> Can you get all of the contributors cleared?
> What’s the architecture? Is it centralized? Is there a sidecar?
Working on it Jeff. Contributors are close to cleared. Copyright is either
Spotify or Stefan, both whom have CLAs in place with ASF.
Licenses of all npm dependencies are good.
> Is there a roadmap or release schedule, so we can get an idea of what
> the Reaper devs have planned for it?
Hi Murukesh,
there's no roadmap per se, as it's open-source and it's the contributions as
they come that make it.
What I know that's in progress or been discussed is:
- more
As an aside, it’s frustrating that ya’ll would sit on this for months (first
e-mail was April); you folks have enough people that know the process to know
that communicating early and often helps avoid duplicating (expensive) work.
The best tech needs to go in and we need to leave ourselves
I don't believe #1 should be an issue, Mick has been reaching out.
Alex and Mick are putting together some architecture documentation, I won't
step on their toes. Currently you can run Reaper as a single instance that
connects to your entire cluster, multiple instances in HA mode, and we're
Is there a roadmap or release schedule, so we can get an idea of what
the Reaper devs have planned for it?
Yours,
Murukesh Mohanan
On Tue, 28 Aug 2018 at 10:02, Jeff Jirsa wrote:
>
> Can you get all of the contributors cleared?
> What’s the architecture? Is it centralized? Is there a sidecar?
Can you get all of the contributors cleared?
What’s the architecture? Is it centralized? Is there a sidecar?
> On Aug 27, 2018, at 5:36 PM, Jonathan Haddad wrote:
>
> Hey folks,
>
> Mick brought this up in the sidecar thread, but I wanted to have a clear /
> separate discussion about what
Hey folks,
Mick brought this up in the sidecar thread, but I wanted to have a clear /
separate discussion about what we're thinking with regard to contributing
Reaper to the C* project. In my mind, starting with Reaper is a great way
of having an admin right now, that we know works well at the
19 matches
Mail list logo
