Documentation update and resources cleanup

src/docs/content/docs/backends/_index.md

@@ -8,22 +8,17 @@ weight = 10
 # Backends
 
 Reaper for Apache Cassandra can be used with either an ephemeral memory storage or persistent database. For persistent scalable database storage, a Cassandra cluster can be set up to back Reaper. To use a Cassandra cluster as the backed storage for Reaper set `storageType` to a value of **cassandra** in the Reaper configuration file. **Astra** can also be used as storage backend by setting `storageType` to a value of **astra**. With purge settings tuned appropriately, Reaper's workload should fit perfectly into the free tier of Astra.
-Alternatively, a relational database storage; either H2 or Postgres can be set up to back Reaper. To use one of the relational database options as the backed storage for Reaper set `storageType` to a value of either **h2** or **postrges** in the Reaper configuration file.
 
 Further information on the available storage options is provided in the following section.
 
 * [In-Memory]({{<ref "memory.md" >}})
 * [Cassanda]({{<ref "cassandra.md">}})
-* [PostgresQL]({{<ref "postgres.md">}})
-* [H2]({{<ref "h2.md">}})
 * [Astra]({{<ref "astra.md">}})
 
 Sample YAML files are available in the *[src/packaging/resource](https://github.com/thelastpickle/cassandra-reaper/tree/master/src/packaging/resource)* directory for each of the above storage options:
 
 * cassandra-reaper-memory.yaml
 * cassandra-reaper-cassandra.yaml
-* cassandra-reaper-postgres.yaml
-* cassandra-reaper-h2.yaml
 * cassandra-reaper-astra.yaml
 
 For configuring other aspects of the service, see the available configuration options in the [Configuration Reference](../configuration).

src/docs/content/docs/backends/h2.md

@@ -8,6 +8,8 @@ weight = 2
 
 # H2 Backend
 
+**Removed in v3.0.0**
+
 To use H2 as the persistent storage for Reaper, the `storageType` setting must be set to **h2** in the Reaper configuration YAML file. When using H2 storage, the database will be automatically created under the path configured in the configuration YAML file. An example of how to configure H2 as persistent storage for Reaper can be found in the *[cassandra-reaper-h2.yaml](https://github.com/thelastpickle/cassandra-reaper/blob/master/src/packaging/resource/cassandra-reaper-h2.yaml)*.
 
 

src/docs/content/docs/backends/postgres.md

@@ -7,6 +7,8 @@ weight = 3
 
 # Postgres Backend
 
+**Removed in v3.0.0**
+
 To use PostgreSQL as the persistent storage for Reaper, the `storageType` setting must be set to **postgres** in the Reaper configuration YAML file. The schema will be initialized/upgraded automatically upon startup in the configured database. Ensure that the correct JDBC credentials are specified in the *cassandra-reaper.yaml* to allow object creation. An example of how to configure Postgres as persistent storage for Reaper can be found in the *[cassandra-reaper-postgres.yaml](https://github.com/thelastpickle/cassandra-reaper/blob/master/src/packaging/resource/cassandra-reaper-postgres.yaml)*.
 
 

src/docs/content/docs/configuration/backend_specific.md

@@ -122,6 +122,8 @@ Cassandra native protocol password.
 
 ## H2 or Postgres Database Settings
 
+**Removed in v3.0.0**
+
 The following settings are specific to a Reaper deployment that is backed by either a H2 or Postgres database. An example of the configuration settings for a Postgres database are as follows.
 
 ```yaml

src/docs/content/docs/configuration/docker_vars.md

@@ -221,6 +221,8 @@ Allows Reaper to establish an encrypted connection when establishing a connectio
 
 ## Direct Mapping to H2 or Postgres Backend Configuration Settings
 
+**Removed in v3.0.0**
+
 The Docker environment variables listed in this section map directly to H2/Postgres backend specific settings in the *cassandra-reaper.yaml* configuration file. The following table below lists the Docker environment variables, their associated H2/Postgres backend specific setting in the *cassandra-reaper.yaml* configuration file, and the default value assigned by the Docker container (if any). Definitions for each Docker environment variable can be found via the link to the associated setting.
 
 In order to use the following settings, `REAPER_STORAGE_TYPE` must be set to `h2` or `postgres`.

src/docs/content/docs/configuration/reaper_specific.md

@@ -96,17 +96,17 @@ For security reasons, it is possible that Reaper will have access limited to nod
 
 **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.
 
-**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 trigger repairs from within 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 use either of Apache Cassandra or Postgres as its storage.
+**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 trigger repairs from within 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 use Apache Cassandra or Astra as its storage.
 
 Further information can be found in the [Operating with a Multi DC Cluster](../../usage/multi_dc) section.
 
-**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 use either of Apache Cassandra or Postgres as its storage. In addition, metrics from nodes in remote datacenters must be collected through the storage backend. If any metric is unavailable, the segment will be postponed for later processing.
+**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 use either of Apache Cassandra or Astra as its storage. In addition, metrics from nodes in remote datacenters must be collected through the storage backend. If any metric is unavailable, the segment will be postponed for later processing.
 
 Further information can be found in the [Operating with a Multi DC Cluster](../../usage/multi_dc) section.
 
 **SIDECAR** - requires one reaper instance for each node in the cluster.
 Each Reaper instance is required to have access via JMX to its local node.
-When operating in this mode, Reaper can use either of Apache Cassandra or Postgres as its storage.
+When operating in this mode, Reaper can use either of Apache Cassandra or Astra as its storage.
 
 Further information can be found in the [Sidecar Mode](../../usage/sidecar_mode) section.
 
@@ -397,7 +397,7 @@ Note that to bind the service to all interfaces use value **0.0.0.0** or leave t
 
 Type: *String*
 
-The storage type to use in which Reaper will store its control data. The value must be either **cassandra**, **astra**, **h2**, **memory**, or **postgres**. If the recommended (persistent) storage type **cassandra**, **h2**, or **postgres** is being used, the database client parameters must be specified in the respective `cassandra`, `h2`, or `postgres` section in the configuration file. See the example settings in provided the *[src/packaging/resources](https://github.com/thelastpickle/cassandra-reaper/tree/master/src/packaging/resource)* directory of the repository.
+The storage type to use in which Reaper will store its control data. The value must be either **cassandra**, **astra** or **memory**. If the recommended (persistent) storage type **cassandra**, or **astra** is being used, the database client parameters must be specified in the `cassandra` section in the configuration file. See the example settings in provided the *[src/packaging/resources](https://github.com/thelastpickle/cassandra-reaper/tree/master/src/packaging/resource)* directory of the repository.
 
 <br/>
 

src/docs/content/docs/download/_index.md

@@ -26,52 +26,3 @@ The current development version can be downloaded as Debian/RPM packages in [the
 For a docker image, please see the [Docker](docker) section.
 
 Once the appropriate package has been downloaded, head over to the [Install and Run](install) section.
-
-## Upgrading from 1.2.0/1.2.1 to 1.2.2
-We unfortunately had to break schema migrations for upgrades to 1.2.2 from 1.2.0 and 1.2.1.
-Here is the upgrade procedure for each Reaper backend:
-
-### Cassandra
-
-* Stop all Reaper instances
-* Run the following DDL statement on the backend cluster :
-
-```
-ALTER TABLE reaper_db.repair_unit_v1 DROP repair_thread_count;
-```
-* Upgrade Reaper to 1.2.2 and start it
-
-**Note:** by doing so the number of threads for each existing schedule will revert back to 0, which will be translated to a single repair thread. If you previously had defined a specific number of threads you will need to recreate these schedules or update the `repair_unit_v1` table manually (this field is only useful with Cassandra 2.2, there is no benefit in Cassandra <=2.1 or >=3.0).
-
-### H2
-
-* Stop Reaper
-* Pointing to your current Reaper jar file (located in `/usr/share/cassandra-reaper` for packaged installs), run the following command :
-```
-java -cp /usr/share/cassandra-reaper/cassandra-reaper-1.2.*.jar org.h2.tools.Shell
-```
-When asked, provide the JDBC URL from your Reaper for Apache Cassandra yaml file (for example : `jdbc:h2:~/reaper-db/db;MODE=PostgreSQL`), use the default `Driver` and leave username/password empty.
-Then run the following statements:
-
-```
-ALTER TABLE REPAIR_UNIT DROP COLUMN repair_thread_count;
-ALTER TABLE REPAIR_SEGMENT DROP COLUMN TOKEN_RANGES;
-```
-* Upgrade Reaper to 1.2.2 and start it
-
-**Note:** by doing so the number of threads for each existing schedule will revert back to 0, which will be translated to a single repair thread. If you previously had defined a specific number of threads you will need to recreate these schedules or update the `repair_unit` table manually (this field is only useful with Cassandra 2.2, there is no benefit in Cassandra <=2.1 or >=3.0).
-
-### Postgres
-
-* Stop Reaper
-* Connect to your Postgres database using the psql shell (or any other client) and run the following statements:
-
-```
-ALTER TABLE "repair_unit" DROP COLUMN "repair_thread_count";
-ALTER TABLE "repair_segment" DROP COLUMN "token_ranges";
-```
-* Upgrade Reaper to 1.2.2 and start it
-
-**Note:** by doing so the number of threads for each existing schedule will revert back to 0, which will be translated to a single repair thread. If you previously had defined a specific number of threads you will need to recreate these schedules or update the `repair_unit` table manually (this field is only useful with Cassandra 2.2, there is no benefit in Cassandra <=2.1 or >=3.0).
-
-

src/docs/content/docs/usage/multi_dc_non-distributed.md

@@ -19,7 +19,7 @@ In the case where the JMX port is accessible (with or without authentication) fr
 datacenterAvailability: ALL
 ```
 
-This setup works with all backends : Apache Cassandra, Memory, H2 and Postgres.
+This setup works with all backends : Apache Cassandra, Astra and Memory.
 
 
 {{< screenshot src="/img/singlereaper-multidc-all.png">}}
@@ -44,7 +44,7 @@ Be aware that this setup will not allow to handle backpressure for those remote
 
 If multiple clusters are registered in Reaper it is required that Reaper can access all nodes in at least one data center in each of the registered clusters.
 
-This setup works with all backends : Apache Cassandra, Memory, H2 and Postgres.
+This setup works with all backends : Apache Cassandra, Astra and Memory.
 
 
 {{< screenshot src="/img/singlereaper-multidc-local.png">}}

src/docs/content/faq.md

@@ -3,7 +3,6 @@
 
 ### Why use Reaper instead of noddetool + cron?
 
-
 While it's possible to set up crontab to call nodetool, it requires staggering the crons to ensure overlap is kept to a minimum.  Reaper is able to intelligently schedule repairs to avoid putting too much load on the cluster, avoiding impacting performance.  Reaper also offers a simple UI to schedule repairs as granularly as needed.
 
 
@@ -12,10 +11,9 @@ While it's possible to set up crontab to call nodetool, it requires staggering t
 Yes!  Repair is a necessary anti-entropy mechanism that keeps your cluster consistent.  Without repair, queries at LOCAL_ONE could return incorrect results.  
 
 
-### Why are there four backends?  Which should i use?
+### Which backend is used to store Reaper's data?
 
 When we (The Last Pickle) took over development of Reaper, we found it cumbersome to require a PostGres database in addition to the Cassandra database.  We also knew Reaper would need to be fault tolerant and work across datacenters.  The most straightforward way to do this would be to leverage Cassandra's fault tolerance.  
 
-For small setups, using a local DB (H2) can make sense.  This would allow reaper to run on a single node using EBS for storage.  This is intentionally a very simple design to keep costs down and avoid extra operational work.
-
-For new installations, we're recommending the Cassandra backend as it allows the most flexibility, with the highest level of availability.
+Postgres and H2 were removed starting with v3.0.0 in order to simplify the codebase and feature addition.
+The memory backend is still available for testing purposes.

src/server/src/main/docker/Dockerfile

@@ -62,7 +62,7 @@ ENV REAPER_SEGMENT_COUNT_PER_NODE=64 \
     REAPER_CASS_AUTH_USERNAME="cassandra" \
     REAPER_CASS_AUTH_PASSWORD="cassandra" \
     REAPER_CASS_NATIVE_PROTOCOL_SSL_ENCRYPTION_ENABLED="false" \
-    REAPER_DB_URL="jdbc:h2:/var/lib/cassandra-reaper/db;MODE=PostgreSQL" \
+    REAPER_DB_URL="" \
     REAPER_DB_USERNAME="" \
     REAPER_DB_PASSWORD="" \
     REAPER_METRICS_ENABLED=false \

src/server/src/main/docker/configure-persistence.sh

@@ -98,28 +98,5 @@ fi
 # END cassandra persistence options
 
     ;;
-    "postgres")
-
-# BEGIN postgres persistence options
-cat <<EOT >> /etc/cassandra-reaper.yml
-postgres:
-  url: ${REAPER_DB_URL}
-  user: ${REAPER_DB_USERNAME}
-  password: ${REAPER_DB_PASSWORD}
-EOT
-# END postgres persistence options
-
-    ;;
-    "h2")
-
-# BEGIN h2 persistence options
-cat <<EOT >> /etc/cassandra-reaper.yml
-h2:
-  url: ${REAPER_DB_URL}
-  user: ${REAPER_DB_USERNAME}
-  password: ${REAPER_DB_PASSWORD}
-EOT
-# END h2 persistence options
-
 esac