Add configuration management service #674
Conversation
This sets up a configuration managemet service on a configureable port (which itself is configureable by the configuration management service!). It sets up an HTTP handler on this port whereby GETs to / will deliver the current TOML configuration that Telegraf booted from. POSTs to / will update that configuration. Telegraf can then be restarted from the configuration by sending SIGHUP through existing mechanisms. This configuration management service is not authenticated in any way! It is assumed that this service will only be available behind the firewall.
| @@ -175,6 +178,9 @@ var header = `# Telegraf configuration | |||
| # Override default hostname, if empty use os.Hostname() | |||
| hostname = "" | |||
|
|
|||
| # Set configuration management port | |||
There was a problem hiding this comment.
these should be indented by 2 spaces rather than tabs
|
we have a separate PR for doing configuration management via etcd: #651, would that accomplish the same task? |
|
It would, but Managed Hosting isn't quite at the point where they can make use of it at the moment. Configuration management via Etcd would likely be combined with some larger changes on their side. I'm told that will happen eventually, but this will be easier for them to use for the time being. |
This was previously config-port, which is incorrect. naoina/toml does snake case <-> camel case. Also changed leading tabs to 2 spaces.
|
The service already has the SIGHUP method of telling it to reload it's config, why not just change the config file on disk before sending the SIGHUP? What does having this service running do? I guess what I'm saying is that it doesn't seem any easier to change the file via a POST vs. just changing it on disk directly. |
|
That seems simpler to me... @kfitzpatrick does that ☝️ work for you? |
|
I'm going to close this unless there is significant opposition. Exposing and changing the config file over HTTP seems like a mess IMHO. The SIGHUP mechanism exists for the purpose of reloading the config file on disk, I see this PR creating the following problem very easily:
My main question is: why create this problem? Why not just change the file on disk? |
This sets up a configuration managemet service on a configureable port
(which itself is configureable by the configuration management
service!). It sets up an HTTP handler on this port whereby GETs to /
will deliver the current TOML configuration that Telegraf booted from.
POSTs to / will update that configuration. Telegraf can then be
restarted from the configuration by sending SIGHUP through existing
mechanisms.
This configuration management service is not authenticated in any way!
It is assumed that this service will only be available behind the
firewall.