Today scylla_servers.yaml is generated by a Node Role and Monitoring Role receives it as an input via {{ scylla_servers_yml_path }}.
I suggest to preserve the ability to feed a scylla_server.yaml file from the outside as we do today but also move the auto-generation code into the Monitoring Role.
The code in question simply runs a monitoring_config.yml if generate_monitoring_config is set.
monitoring_config.yml in line effectively calls files/minigenconfig.py --cluster-name {{ scylla_cluster_name }} --api-string http://{{ scylla_api_address }}:{{ scylla_api_port }} on the first node in the hosts list.
I don't see any reason why a Monitoring Role can't run the same if needed.
And it seems rather wrong (abstraction leaking) that one Role generates configs for another Role if that other Role is quite capable to do that itself.
igorribeiroduarte
commented
4 months ago
Today scylla_servers.yaml is generated by a Node Role and Monitoring Role receives it as an input via
{{ scylla_servers_yml_path }}.I suggest to preserve the ability to feed a
scylla_server.yamlfile from the outside as we do today but also move the auto-generation code into the Monitoring Role.The code in question simply runs a
monitoring_config.ymlifgenerate_monitoring_configis set.monitoring_config.ymlin line effectively callsfiles/minigenconfig.py --cluster-name {{ scylla_cluster_name }} --api-string http://{{ scylla_api_address }}:{{ scylla_api_port }}on the first node in the hosts list.I don't see any reason why a Monitoring Role can't run the same if needed. And it seems rather wrong (abstraction leaking) that one Role generates configs for another Role if that other Role is quite capable to do that itself.