Right, I understand the arguments for starting a new project. I’m not saying
reaper is, technically speaking, the best place to start. The point I’m trying
to make is that the non-technical advantages of using an existing project as a
starting point may outweigh the technical benefits of a clean
The benefit is that it more closely matched the design doc, from 5 months ago,
which is decidedly not about coordinating repair - it’s about a general purpose
management tool, where repair is one of many proposed tasks
https://docs.google.com/document/d/1UV9pE81NaIUF3g4L1wxq09nT11AkSQcMijgLFwGsY
> What’s the benefit of doing it that way vs starting with reaper and
> integrating the netflix scheduler? If reaper was just a really inappropriate
> choice for the cassandra management process, I could see that being a better
> approach, but I don’t think that’s the case.
>
The benefit, as Din
> Periodic SNAPSHOT builds sounds great. I'd feel much better about builds
> published as date- or SHA-stamped snapshots / nightlies rather than
> calling them alphas at this point, as everyone's testing work is
> beginning. Can someone offer details on what would need to be done to
> publish
> I think we should accept the reaper project as is and make that
cassandra management process 1.0, then integrate the Netflix scheduler (and
other new features) into that.
Integrating Netflix scheduler into reaper is mostly refactoring reaper code
since they are different architectures.
> Reaper
What’s the benefit of doing it that way vs starting with reaper and integrating
the netflix scheduler? If reaper was just a really inappropriate choice for the
cassandra management process, I could see that being a better approach, but I
don’t think that’s the case.
If our management process is
> How can we continue moving this forward?
>
> Mick/Jon/TLP folks, is there a path here where we commit the
> Netflix-provided management process, and you augment Reaper to work with it?
> Is there a way we can make a larger umbrella that's modular that can
> support either/both?
There seems a
I’d also like to see the end state you describe: reaper UI wrapping the Netflix
management process with pluggable scheduling (either as is with reaper now, or
using the Netflix scheduler), but I don’t think that means we need to start
with reaper - if personally prefer the opposite direction, st
On Fri, Sep 7, 2018 at 5:03 PM Jonathan Haddad wrote:
>
> We haven’t even defined any requirements for an admin tool. It’s hard to
> make a case for anything without agreement on what we’re trying to build.
>
We were/are trying to sketch out scope/requirements in the #14395 and
#14346 tickets as w
I think we should accept the reaper project as is and make that cassandra
management process 1.0, then integrate the netflix scheduler (and other new
features) into that.
The ultimate goal would be for the netflix scheduler to become the default
repair scheduler, but I think using reaper as the
We haven’t even defined any requirements for an admin tool. It’s hard to
make a case for anything without agreement on what we’re trying to build.
On Fri, Sep 7, 2018 at 7:17 PM Jeff Jirsa wrote:
> How can we continue moving this forward?
>
> Mick/Jon/TLP folks, is there a path here where we com
How can we continue moving this forward?
Mick/Jon/TLP folks, is there a path here where we commit the
Netflix-provided management process, and you augment Reaper to work with it?
Is there a way we can make a larger umbrella that's modular that can
support either/both?
Does anyone believe there's a
Thanks for getting started with performance testing - this is exciting to hear!
Periodic SNAPSHOT builds sounds great. I'd feel much better about builds
published as date- or SHA-stamped snapshots / nightlies rather than calling
them alphas at this point, as everyone's testing work is beginning.
I don't think anyone has mentioned this yet but we probably want to
consider releasing 4.0 alpha jars to maven central soon so the open
source ecosystem can start testing a consistent Cassandra 4.0; for
example I had to hack 4.0 into Priam's build [1] by manually building
a jar and checking it in w
Really good idea JD. Keeping all the tests under an umbrella ticket for the
feature with everything linked back makes a lot of sense.
On Thu, Sep 6, 2018 at 11:09 PM J. D. Jordan
wrote:
> I would suggest that JIRA’s tagged as 4.0 blockers be created for the list
> once it is fleshed out. Test p
I would like to contribute as well.
Best,
Hyunsoo
On Fri., Sep. 7, 2018, 7:22 a.m. Per Otterström, <
per.otterst...@ericsson.com> wrote:
> This is a great initiative! If we can create a structured verification
> approach on new and old features I think 4.0 will be up for a good start.
> Jon, you
This is a great initiative! If we can create a structured verification approach
on new and old features I think 4.0 will be up for a good start. Jon, you can
add my team to that signup sheet.
/pelle
-Original Message-
From: Varun Barala
Sent: den 6 september 2018 15:16
To: dev@cassand
17 matches
Mail list logo
