Improving docs

[rustyrazorblade]

I've broken up the docs into sections, which should make them easier to maintain. We'll probably want to split out how to install on the different OSes, config options, and REST endpoints.

[ossarga]

Good work on splitting out the document into different sections. It makes it so much more easier to follow! I have a some comments on wording/formatting for consideration.

[ossarga]

We should probably make this a H1 level heading so it is consistent with the rest of the pages, i.e. change ## to #

Consider rewording this heading to

# Building Install Packages

[rustyrazorblade]

Done.

[ossarga]

What are your thoughts on changing RPM to Red Hat?

[rustyrazorblade]

The wording is a little weird, how's this feel:

Debian packages and RPMs can be built from this project using Make, for example:

[ossarga]

Same as previous comment about H1 level heading; change ## to #

Consider rewording this heading to

# Building JAR Package

[rustyrazorblade]

How's "Building JARs from source" feel?

[ossarga]

Probably insert a heading here for the Docker image.

# Building Docker Image

[rustyrazorblade]

Done

[ossarga]

👍

[ossarga]

Change this to be # Building using Docker

Then remove the commands below as they are already in the Docker section of the document. Replace the commands with a link to the Docker section that talks about building using Docker.

[rustyrazorblade]

Done

[ossarga]

Insert the following sentence in before the one above.

To use PostgreSQL as the persistent storage for Reaper, the storageType setting must be set to database in the Reaper configuration YAML file.

[ossarga]

Reword this sentence to be something like

Ensure that the correct JDBC credentials are specified in the cassandra-reaper.yaml to allow object creation.

[ossarga]

Consider restyling this heading to a H2 level heading i.e. change to ##

Consider renaming the heading to

Reaper Specific Configuration Settings

[ossarga]

Minor reword change

...specific configuration values are:

to

...specific configuration settings are:

[ossarga]

Consider removing this heading. The reason being this section talks about configuration and we are putting in a topic about Multi-DC. We can still talk about multi-DC setup in the datacenterAvailability option. Here is some suggested wording to replace what is below.

`datacenterAvailability:`

Indicates to Reapers its deployment in relation to cluster data center network locality. The value can be either **ALL** (default value), **LOCAL**, or **EACH**. Note that the `datacenterAvailability` setting controls the behavior for metrics collection.

For security reasons, it is possible that Reaper will have access limited to nodes in a single datacenter via JMX (multi region clusters for example). In this case, it is possible to deploy an operate an instance of Reaper in each datacenter where each instance only has access via JMX (with or without authentication) to the nodes in its local datacenter. Where multiple instances of Reaper are in operation in this configuration, only the Apache Cassandra storage option can be used with Reaper. All other storage options are unsuitable in this case. This is because Reaper instances will rely on lightweight transactions to get leadership on segments before processing them. In addition, Reaper will check the number of pending compactions and actively running repairs on all replicas prior to processing a segment.

Setting the value to **ALL** requires Reaper to have access via JMX to all nodes across all datacenters. In this mode Reaper can be backed by all available storage types.

Setting the value to **LOCAL** requires Reaper to have access via JMX to all nodes only in the same datacenter local to Reaper. A single Reaper instance can operate in this mode and repair its local data center. In this case, can be backed by all available storage types and repairs to any remote datacenters are be handled internally by Cassandra. A Reaper instance can be deployed to each datacenter and be configured to operate in this mode. In this case, Reaper can only use Apache Cassandra as its storage. In addition, metrics can be collected asynchronously through the Apache Cassandra storage.

Setting the value to **EACH** requires a minimum of one Reaper instance operating in each datacenter. Each Reaper instance is required to have access via JMX to all nodes only in its local datacenter. When operating in this mode, Reaper can only use Apache Cassandra as its storage. In addition, metrics from nodes in remote datacenters must be collected through the Cassandra storage backend. If all metrics unavailable, the segment will be postponed for later processing.