adejanovski
commented
1 year ago Hi @jahstreet, we wanted to add support for it back then but couldn't figure out how to track the major compactions that we could trigger like we monitor repairs. The storage service api doesn't return any id (as far as I remember) in the forceCompaction method, so we can fire them but then lose track. One of the things we wanted to do with it still was allowing to automatically trigger major compactions after a successful repair as an option. It wouldn't require tracking the compaction, although it would create the risk of running another repair while the major compaction is running, which wouldn't be great. Maybe 4.0+ versions of cassandra now allow to track compactions, which would then open the possibility of managing major compactions through Reaper safely.
Project board link
Good day.
We run K8ssandra Operator and consider using Reaper not only for repairs but also for major compactions. I see in the code that CopactionProxy#forceCompaction function exists, but it seems to be unused. What was the reason to have/keep it?
What are your opinions on exposing it to UI for triggering and scheduling major compactions? Happy to pick up that patch in case there is an interest, but first wanna check with the maintainers and community on the reasonability of such a feature.
┆Issue is synchronized with this Jira Story by Unito ┆Issue Number: REAP-42