Support configuration reload #48
Conversation
Accept SIGHUP to reload the configuration. This stops all polling and forces all advertised services to be deregistered (and then reloaded) in the discovery service.
|
@tgross looks solid to me |
Passing around config as a context to functions would be the ideomatic way. But we need to support configuration reload from signals and have that reload effect function calls in the main goroutine. Wherever possible we should be accessing via `getConfig` at the "top" of a goroutine and then use the config as context for a function after that.
| config.QuitChannels = quit | ||
|
|
||
| // gracefully clean up so that our docker logs aren't cluttered after an exit 0 | ||
| // TODO: do we really need this? |
There was a problem hiding this comment.
Tested this and it turns out the answer is no, so I cut it.
|
@misterbisson and @justenwalker I've got this wrapped up. I've added a global (protected by a mutex) that stores the configuration so that top-level functions can get the new config at the time they're called, rather than at the time their caller is called. I'm not super-wild about how whether we're calling My integration test (which I definitely do want to get added to our automation at some point as per #42): $ make run
...
$ docker exec -it example_nginx_1 /bin/bash
root@17f38ba6e2c6:/# sed -i 's/80/8080/' /opt/containerbuddy/nginx.json
root@17f38ba6e2c6:/# kill -HUP 1
root@17f38ba6e2c6:/# exitAnd then it's easy to verify by watching what Consul is doing. |
|
🏡 🚶 |
@misterbisson @justenwalker this PR supports reloading the configuration (ref #9). This is not a completed implementation, but I figure getting in front of you guys would be a good idea. There will also almost certainly be merge conflicts with #46 so I'll be sure to clean those up first.
We accept SIGHUP to reload the configuration. This stops all polling and forces all advertised services to be deregistered (and then reloaded) in the discovery service. We have to do this because otherwise we can't actually update service configurations in Consul.
Right now the fairly large hole in the implementation that I'm planning on taking on starting tomorrow morning is that we don't properly cover theDonepreStopandpostStopfunctions. We pass their config struct inmain, which is outside the loop for getting the config. It's just a bit of refactoring so we can stick the config in at the appropriate moment.