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 the reaper core / UI (api / front end ). It has a lot of potential — specifically if the API / Services / UI could be modularized and leverage IoC to add functionality via configuration not code. There are a lot good conventions in both open source and commercial projects out there for web based administration tools. The most successful ones do the basics related to their tool well and leave the rest to other systems. The pitfall I don’t want the valuable talent to enter in this group is to reinvent the wheel on things that other tools do well and focus on what Admins/ Architects/ Developers need. Eg. if Prometheus and Grafana are good for stats, keep it - just make it easier to facilitate or compose in Docker. Another example : There are ideas I had including a data / browser / interactive query interface — but Redash or Zeppelin do a good job for the time being and no matter how much time I spend on it I probably wouldn’t want make a better one. Rahul Singh Chief Executive Officer m 202.905.2818 Anant Corporation 1010 Wisconsin Ave NW, Suite 250 Washington, D.C. 20007 We build and manage digital business technology platforms. On Aug 27, 2018, 9:22 PM -0400, Mick Semb Wever <m...@apache.org>, wrote: > > > 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 thorough upgrade tests, > - support for diagnostic events (C* 4.0), > - more task/operations: compactions, cleanups, sstableupgrades, etc etc, > - more metrics (better visualisations, for example see the newly added > streaming), > - making the scheduler repair-agnostic (so any task/operation can be > scheduled), and > - making task/operations not based on jmx calls (preparing for non-jmx type > tasks). > > regards, > Mick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org >
