We can wait for a week post Freeze so everyone can participate however we need
to decide after that so we can make progress.
I am leaning towards piecemeal approach so we can review the code and pick best
of all 3 options
> On Aug 29, 2018, at 00:26, kurt greaves wrote:
>
> 2c: There's a lot
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 ar
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 should
> 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
engin
> 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 replacin
> 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 actual
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
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.
T
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 engi
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 wi
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
simple
> 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 po
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 th
> 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. Still
> 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 thoro
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 wit
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
finis
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 we'r
19 matches
Mail list logo
