michaelsembwever
commented
5 years ago We've been trying to move away from putting application data (how clusters in a running Reaper are registered and their schedules) into the main cassandra-reaper.yaml configuration. The goal of that configuration file being mainly about the configuration of Reaper itself.
One of the approaches discussed has been to take all per-cluster configuration settings out of that file, and into the UI and command-line tool spreaper.
Then to do such things automatically it would require them to be scripted as a post-startup script, using spreaper.
Reaper is running in a few places where it is an immutable docker container, and the vanilla Reaper image is wrapped with a custom docker image that adds such a post-startup script. (Such a script can also run the pre-startup steps of creating the reaper_db keyspace.)
Much of the work that went into improving the idempotence and response status codes of the REST API in Reaper 1.2.0 ( https://github.com/thelastpickle/cassandra-reaper/releases/tag/1.2.2 ) was around making these scripts working smoothly (you could run the post-startup script every Reaper restart and if clusters and schedules were already configured it would not duplicate them). Also, for example this comment: https://github.com/thelastpickle/cassandra-reaper/pull/425#issuecomment-392415074
As you've indicated separate configuration files for auto-scheduling, that is that auto-scheduling would be removed from the cassandra-reaper.yaml, I'm interested. I don't see it necessarily conflicting with what I've written above, mostly I wrote all of that so you knew where we were and what we have otherwise been thinking.
adejanovski
Project board link
We are thinking of extending auto scheduling to have different configs for each cluster and keyspace. Just wanted to get early thoughts on this.
High level design:
┆Issue is synchronized with this Jira Story by Unito ┆Issue Number: REAP-157