You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 31, 2022. It is now read-only.
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.
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 freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Instead of relying on a outside data source, like Postgres, it would make sense to keep the state inside Cassandra, in a separate keyspace.
The text was updated successfully, but these errors were encountered: