Monday follow-up: There exist a lot of tools that a lot of people know exist and use for managing clusters. Examples are repair scripts like - https://github.com/spotify/cassandra-reaper - https://github.com/BrianGallew/cassandra_range_repair - https://github.com/thelastpickle/cassandra-reaper
Or cassandra puppet modules: - https://github.com/locp/cassandra Or Brian Hess' counter+loader tools: - https://github.com/brianmhess/cassandra-count - https://github.com/brianmhess/cassandra-loader Or Brian Gallew's tools at: - https://github.com/BrianGallew/cassandra_tools I'd like to make a more comprehensive list of these third party tools and include them in the docs - are there any tools you find useful in using Cassandra that should be listed? On Sun, Apr 2, 2017 at 7:53 PM, Jeff Jirsa <jji...@gmail.com> wrote: > From the email list: > > 1) Some grad students are doing some research on Cassandra and have open > questions about thread interactions - would be great if someone had time to > help answer their questions: https://lists.apache.org/thread.html/ > 70ae332f54676352755bcb421b66a56fe27e296f8828eff26727bb58@% > 3Cdev.cassandra.apache.org%3E > > 2) The ongoing discussion of code quality, testing, and coverage continues > - if you haven't read it yet, but you care about release quality, you > probably should ( https://lists.apache.org/thread.html/ > 0854341ae3ab41ceed2ae8a03f2486cf2325e4fca6fd800bf4297dd4@% > 3Cdev.cassandra.apache.org%3E ) > > 3) As a follow-up to #2, I proposed pushing up some CircleCI and Travis > YML files into the active branches to make testing easier - ( > https://lists.apache.org/thread.html/48e73ff0d2aff5af3d6feb20af5e7f > 4318c17379471abb2c16c2dcdf@%3Cdev.cassandra.apache.org%3E / > https://issues.apache.org/jira/browse/CASSANDRA-13388 ). If anyone has > strong opinions on Circle/Travis, or is great with setting up yaml files to > configure parallel CI tests, wouldn't mind having some feedback here (like > "we can split up nosetests like ____", or "let's use ____ instead because > it'll be easier", or "just push it as is and we'll iterate on it later" - > I'm personally leaning towards "push it and iterate later", since it's not > actually impacting the database at runtime, but other feedback is always > great) > > > JIRA stuff: > > - https://issues.apache.org/jira/browse/CASSANDRA-13396 - we use SLF4J, > but really only support logback (though we didn't actively exclude other > loggers until recently); people with long histories working on the project > (especially you Datastax and TLP folks), may want to throw in their two > cents on this ticket. People commenting should endeavor to keep things fact > based, and not emotional. > > Some more patch-available JIRAs but no reviewers: > - https://issues.apache.org/jira/browse/CASSANDRA-13397 (Return value of > CountDownLatch.await() not being checked in Repair ) > - https://issues.apache.org/jira/browse/CASSANDRA-13307 (Make CQLSH Great > Again by making CQLSH downgrade native protocol properly) > - https://issues.apache.org/jira/browse/CASSANDRA-12962 (SASI needlessly > rebuilding empty indices) > - https://issues.apache.org/jira/browse/CASSANDRA-13067 (Huge AWS > filesystems overflow Long.MAX_INT) > - https://issues.apache.org/jira/browse/CASSANDRA-12748 (GREP_COLOR > environment variable breaks things) > And These two BTree related patches have been around a while, still no > reviewer: > - https://issues.apache.org/jira/browse/CASSANDRA-9989 & > https://issues.apache.org/jira/browse/CASSANDRA-9988 > > - Jeff >
