Open prannonpendragas opened 1 year ago
Thanks for reporting it @prannonpendragas
We planning to separate the playbooks configuration from the values file, and the secrets that are in it. It's on our plans for Q2
Once we start working on it, I'd love to share the details and get your feedback
Hi! Is there any progress on this?
Hey, not updates yet. But if you are interested in working on this, we are happy to provide guidance and PRs are more than welcome!
Is your feature request related to a problem? In https://docs.robusta.dev/master/user-guide/additional-playbooks.html, it is described how one can configure Robusta to clone a remote repo to load up additional Playbook actions. My initial read on these instructions was that you could load up custom python automations, and that you could also load up further customPlaybooks configurations.
This concept is neat and convenient and low friction, since one can update the automations and the automation configurations remotely, outside of any helm values, and then just tell Robusta to pull down the latest configs with a simple and easy-to-integrate CLI command.
However, on further reading and also on review of the relevant code in the app, I'm not so sure that remote loading of
customPlaybooks
is supported. It seems like this feature is only intended for loading up custom python playbook actions.To my view this increases the friction for configuration updates. Instead of being able to store the
customPlaybooks
in a remote repo and then tell Robusta to pull it down and update its configuration, I would need to maintain thegenerated_values.yaml
helm values (which contains secrets) and then set up some sort of external framework to push that to robusta whenever we need to update the configuration.Describe the solution you'd like This is my thinking:
customPlaybooks
will change often as operators and engineers assess their needs, learn lessons from monitoring, adjust settings, and invent new automations.globalConfig
,sinksConfig
,rsa
, and so forth are unlikely to be changed often. These items also contain secrets, which will need to be managed separately.Given this paradigm, it should be possible to manage these things separately, and it should be as frictionless as possible to manage and update
customPlaybooks
along with the playbook actions.I would like to be able to configure
playbookRepos
that don't just load playbook actions, butcustomPlaybooks
configurations as well.Describe alternatives you've considered I've considered two alternatives.
It isn't that difficult or high friction to continue using Helm to update Robusta's configuration. I can easily store the generated_values.yaml file and any additional configuration files in a git repository, and then set up a framework to update Robusta easily.
At that point, though, I'm considering the additional footprint needed to manage secrets within that repository, as helm will not allow you to upgrade a release without having the whole set of values. It would be nice if - when just managing the
customPlaybooks
- I did not have to concern myself with secrets management.I've also considered a rather silly and hacky option, where I can set up a
playbookRepo
to store any custom playbook actions that I develop along with the contents of the/etc/robusta/config/active_playbooks.yaml
file, plus any additional configurations I might want. I can then set up an additional_env_var that sets PLAYBOOKS_CONFIG_FILE_PATH to my git loaded configuration file.This is cludgy, though, and it still requires me to manage the
customPlaybooks
and the configs containing secrets in the same place.Additional context I'm completely open to having this feature request rejected if I am misunderstanding the way that the Robusta configuration is meant to be managed, or if I'm not considering some other alternative.
In the end, though, it just makes sense to me that if you can manage additional playbook actions using Git, you should also be able to manage the Robusta configuration - especially
customPlaybooks
- using Git as well.