Add an agent API to manage watches

[slackpad]

Capturing this after the discussion here - https://groups.google.com/d/msgid/consul-tool/01b167e3-be26-4bcb-ba61-0836bcd1e3c6%40googlegroups.com?utm_medium=email&utm_source=footer.

[fdhex]

I would actually very much support this.

[bgilner]

I would find this useful as it is very hacky to implement a workaround. My micro-service not only has to know where the consul url is but now a path to the executable just to run a consul watch command that invokes powershell that invokes a webrequest that my controller uses to reload settings.

More painful since consul.exe must either be added to the path of each environment or relative to each consuming service.

[shcherbachev]

I vote for this feature as well.

We have an HTTP endpoint listening for "watch" events implemented as a part of our service. Having to register a watch via agent's configuration files isn't that handy since services tend to go up and down.

It would be nice to have either: 1) "watches" section available as a part of service definition 2) http api so we can register/deregister a watch dynamically at service startup/shutdown 3) get the HTTP handler type improved so it can point to a Consul's service (hostname name and port). I can use Consul's DNS record in http action right now, but not the port number. Plus we need an option to notify all service instances, not just one.

Personally, I prefer #3. Imagenary config with two new attributes: service, broadcast, and path starting with /:

"handler_type": "http",
"http_handler_config": {
    "service":"my_service",
    "broadcast":"true",
    "path":"/watch",
    "method": "POST"
}

[boostbob]

cool feature, plz think about this.

[bdhayakar]

This feature will be helpful.

[HuangDayu]

So, does version 1.8.5 support this new feature?