Skip to content
This repository has been archived by the owner on Mar 31, 2022. It is now read-only.

Keep raeper state inside Cassandra #104

Open
nathan-gs opened this issue Jun 19, 2015 · 3 comments
Open

Keep raeper state inside Cassandra #104

nathan-gs opened this issue Jun 19, 2015 · 3 comments

Comments

@nathan-gs
Copy link

Instead of relying on a outside data source, like Postgres, it would make sense to keep the state inside Cassandra, in a separate keyspace.

@Bj0rnen
Copy link
Contributor

Bj0rnen commented Jun 29, 2015

There would be 2 ways to go about this, when using one Reaper for many clusters:

  • Configure a dedicated Reaper cluster, which holds this keyspace.
  • Add all clusters to the Reaper's config, and let them all hold state of their own repairs.

The first one is pretty straight-forward. It's just another implementation of IStorage.

The second option is also clearly possible, considering there is no cross-cluster state. Except the info of which clusters there are, which would now be moved to the config. But it would not play well with IStorage, since Reaper wouldn't know how to map IDs to clusters. Either all clusters would have to be asked, or a bigger rewrite would be needed to accommodate for this.

Which one of these options did you have in mind?

@nathan-gs
Copy link
Author

The second option would have my preference.

Option 1 would also work in the mean time, especially if it can be the same cluster as it's monitoring.

@yingzong
Copy link

I disagree. It is a bad idea for any maintenance state to be stored in the system being maintained. It should be totally independent. DataStax's OpsCenter made that grievous mistake.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants