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.
This will basically make the root directory a place for storing the
major telegraf interfaces, which will make telegraf's godoc looks quite
a bit nicer. And make it easier for contributors to lookup the few data
types that they actually care about.
closes#564
We are unifying the way that we handle configuration across the products
into the influxdata/config package. This provides the same API as
naoina/toml that was used previously, but provides some additional
features such as support for documenting generated TOML configs as well
as support for handling default options. This replaces all usage of
naoina/toml with influxdata/config.
Reuses same logic as the plugins for filtering points, should be only
a marginal performance decrease to check all the points before writing
to the output.
Added examples to the README as well (for generic pass/drop as well as
output pass/drop/tagpass/tagdrop).
X-Github-Closes #398closes#398closes#401
godep seems to have a problem when dependencies have `internal`
packages. So removing `godep go build` and `godep go test` from the
build process in favor of just checking out the correct revisions using
`godep restore` into the regular GOPATH.
This basically means that we are not actually using anything within the
Godeps directory except Godeps.json. I should probably make a separate
go dependency management system that does this.