> 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 Dinesh and I argued earlier, is starting without technical debt (especially architectural technical debt) and taking only the best components from the multiple community sidecars for the Cassandra management sidecar. To be clear, I think Priam is much closer to the proposed management sidecar than Reaper is (and Priam + the repair scheduler has basically all proposed scope), but like I said earlier in the other thread I don't think we should take Priam as is due to technical debt and I don't think we should take Reaper either. The community should learn from the many sidecars we've built and solve the problem once inside the Cassandra sidecar.
> If our management process isn’t a drop in replacement for reaper, then reaper > will continue to exist, which will split the user and developers base between > the 2 projects. That won't be good for either project. I think Reaper is a great repair tool for some infrastructures, but I don't think the management sidecar is about running repairs. It's about building a general purpose tool that may happen to run repairs if someone chooses to use that particular plugin. To be honest I think it's great that there are competing community repair tools ... this is how we learn from all of them and build the simplest and most narrowly tailored solution into the database itself... -Joey --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
