When using cassandra storage type, automatically generate requested keyspace if it doesn't exist.

[chrislbs]

At present, whenever you startup cassandra-reaper using cassandra as the persistent storage, it doesn't create the keyspace specified in the configuration file if it didn't already exist in the cluster.

Ideally, this would be done in CassandraStorage.java before acquiring the session using the keyspace.

I noticed the following line commented out in the the initialize_db.cql file.

-- CREATE KEYSPACE IF NOT EXISTS reaper_db WITH REPLICATION={'class':'SimpleStrategy', 'replication_factor':3};

The problem with this approach is if the user wants to use a different replication factor or other options with the keyspace creation. Unfortunately, the configuration of the keyspace is also specified within the dropwizard-cassandra dependency so it will be difficult to extend the cassandra: section of the yml file as it is based on that dependency.

Some ideas:

• Add additional configuration outside of the cassandra: section that are specific to the type of of storage in use. e.g. storageOptions: { type: cassandra, replicationStrategy: SimpleStrategy, replicationFactor: 3 }
• Create a dropwizard command that takes additional command line arguments for the the replication strategy and replication factor

[adejanovski]

I had the same idea when adding automatic schema migration in the codebase, and thought we should create the keyspace automatically.

I concluded that this was not a good idea for a couple reasons :

• ops need to set the replication strategy explicitly to avoid consistency issues as Reaper uses LOCAL_QUORUM by default (and that's overall a C* best practice, especially as we do not own the clusters that Reaper will get installed on)
• Technically, this would require to hack the way dropwizard-cassandra works in order to create a keyspace with our arbitrary number of replicas. Currently, I found now way to do this properly unless I created multiple connections to the cluster.

Given that the benefits are really up to debate, I'd rather not add hacky stuff in the code to perform the KS creation.

[michaelsembwever]

Given that the benefits are really up to debate, I'd rather not add hacky stuff in the code to perform the KS creation.

Agreed.
This works with in-house code where you can, through environment profiles in the configuration, define the keyspace RF per environment.
In open source we don't know what the RF should be for a user, and should just leave keyspace creation logic alone.

[chrislbs]

Sounds arguments against. I'll go ahead and close this.