Add OnRestartFailed to the ready plugin and some various cleanups.
Document slightly better how things are supposed to work with multiple
`ready`'s in the multiple Server Blocks.
All manually tested with this Corefile:
~~~
. {
log
ready
}
example.org {
log
chaos
ready
}
~~~
And then `kill -SIGUSR1` and curling the ready endpoint. This works
well, the FailedReload is triggered by adding a syntax error in the
Corefile.
See #2659
Signed-off-by: Miek Gieben <miek@miek.nl>
Add a ready plugin that allows plugin to signal when they are ready.
Once a plugin is ready it is not queried again.
This uses same mechanism as the health plugin: each plugin needs to
implement an interface.
Implement readines for the *erratic* plugin to aid in testing.
Add README.md and tests moduled after the health plugin; which will be
relegated to just providing process health. In similar vein to health
this is a process wide setting.
With this Corefile:
~~~
. {
erratic
whoami
ready
}
bla {
erratic
whoami
}
~~~
ready will lead to:
~~~ sh
% curl localhost:8181/ready
% dig @localhost -p 1053 mx example.org
% curl localhost:8181/ready
OK%
~~~
Meanwhile CoreDNS logs:
~~~
.:1053
bla.:1053
2019-02-26T20:59:07.137Z [INFO] CoreDNS-1.3.1
2019-02-26T20:59:07.137Z [INFO] linux/amd64, go1.11.4,
CoreDNS-1.3.1
linux/amd64, go1.11.4,
2019-02-26T20:59:11.415Z [INFO] plugin/ready: Still waiting on: "erratic"
2019-02-26T20:59:13.510Z [INFO] plugin/ready: Still waiting on: "erratic"
~~~
*ready* can be used in multiple server blocks and will do the right
thing; query all those plugins from all server blocks for readiness.
This does a similar thing to the prometheus plugin.
Signed-off-by: Miek Gieben <miek@miek.nl>
