Consul: Watches for Go API

[poy]

Is there any way to setup a watch to call a function within the API? Or do you have to use the command line consul watch that then requires a script?

[ryanuber]

Hey @apoydence, currently you can do this in two ways:

1. Use consul watch and invoke a script based on its output
2. Configure a watch in consul with a script handler to invoke the API.

There is no in-built way to automatically query the internal API, but using watch handlers you should be able to do just about whatever you want to in a few lines of code.

[poy]

Hey @ryanuber, I might have missed it, but I didn't see anywhere in the linked document to do this any other way besides the first way (script based).

[ryanuber]

@apoydence you are correct that you would still need a script. You can use the command-line consul watch to create a watch as an external process, or you can configure Consul with internal watches, which fire the handler script that you configure. This helps reduce the number of moving parts.

[poy]

@ryanuber Are there any plans to expand the functionality of watches? Meaning, in the future will we be able to do it programmatically?

[armon]

@apoydence I'm not sure what you mean. Watches are just a convenient abstraction around doing blocking queries programatically. Those are the underlying API that enables watchers. See the "Blocking Queries": https://consul.io/docs/agent/http.html

[poy]

@armon Ah, I didn't notice that the service endpoint had noted to have blocking queries. I will look into those. Thanks!

[cthumuluru]

@apoydence I've a question around the usage of watches. I'm new to Consul and started looking at the documentation to use it for our use cases. I see the maximum time a blocking query can wait is 10 mins. Is there a reason for this upper cap? We were planning to use watches for job completion notifications where the job could take more than 10 mins. Are blocking queries the right ones to use or Consul offers any other functionality?

[poy]

@cthumuluru 10 minutes is a long time and many proxies have limits for an inactive connections (e.g. 1 minute on an AWS elb) and therefore your code should assume timeouts (simply reconnect when they do). I believe watches are a powerful tool sound relevant for your solution.

[dlsniper]

I would like to propose reopening this issue.

The use-case that I have is that I don't want to set up a CLI to do the watch / execution for me, but rather have this self-contained in the application logic. I know how to handle API calls that are blocking and I can definitely launch goroutines and use Go channels as needed. Having to workaround this by reusing the whole code in github.com/hashicorp/consulwatch is just not a good idea and I'd much rather have this inside the API code. I know I can emulate this by having a timer and continuously watch keys but that way is also less desirable than just having the API call available inside the client API.

What do you think?

[slackpad]

Hi @dlsniper Consul's watch package https://github.com/hashicorp/consul/tree/master/watch is pretty easy to re-use if you need it, and is basically a wrapper around the API. I think it makes sense to leave it as a separate package since it's not a first-class part of Consul's API, and more of a composition on top of it, which keeps the role of the API package clearer.