-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add *ready* plugin #2616
Add *ready* plugin #2616
Conversation
Thank you for your contribution. I've just checked the OWNERS files to find a suitable reviewer. This search was successful and I've asked greenpau (via If you have questions or suggestions for this bot, please file an issue against the miekg/dreck repository. The bot understands the commands that are listed here. |
c.OnStartup(r.wait) | ||
c.OnRestart(r.onRestart) | ||
c.OnFinalShutdown(r.onFinalShutdown) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks to the new "OnRestartFailed" event that was introduced few months ago in Caddy.
We can handle the failed restart (when the Corefile is invalid).
i guess we could have:
c.OnStartup(r.onStartup)
c.OnStartup(r.wait)
c.OnRestart(r.onRestart)
c.OnRestartFailed(r.onStartup)
c.OnRestartFailed(r.wait)
c.OnFinalShutdown(r.onFinalShutdown)
[ Quoting <notifications@github.com> in "Re: [coredns/coredns] Add *ready* p..." ]
fturib commented on this pull request.
> + })
+}
+
+func setup(c *caddy.Controller) error {
+ addr, err := parse(c)
+ if err != nil {
+ return plugin.Error("ready", err)
+ }
+
+ r := new(addr)
+
+ c.OnStartup(r.onStartup)
+ c.OnStartup(r.wait)
+ c.OnRestart(r.onRestart)
+ c.OnFinalShutdown(r.onFinalShutdown)
+
Thanks to the new "OnRestartFailed" event that was introduced few months ago in Caddy.
We can handle the failed restart (when the Corefile is invalid).
i guess we could have:
```
c.OnStartup(r.onStartup)
c.OnStartup(r.wait)
c.OnRestart(r.onRestart)
c.OnRestartFailed(r.onStartup)
c.OnRestartFailed(r.wait)
c.OnFinalShutdown(r.onFinalShutdown)
```
oh, that's awesome!
|
Codecov Report
@@ Coverage Diff @@
## master #2616 +/- ##
=========================================
+ Coverage 55.56% 55.66% +0.1%
=========================================
Files 203 207 +4
Lines 10307 10408 +101
=========================================
+ Hits 5727 5794 +67
- Misses 4150 4180 +30
- Partials 430 434 +4
Continue to review full report at Codecov.
|
Thanks for adding this, although, I was thinking we'd just need report readiness (and not actually block serving until all plugins are ready). |
fair point. It's also global in that it crosses server block boundaries in the current impl. That's not good and counter intuitive; meaning should look even more like health |
ok, reworked it to; |
io.WriteString(w, "OK") | ||
return | ||
} | ||
log.Infof("Still waiting on: %q", todo) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason not to also write this to the body of the response? A 500 error can still have a body. Something like {"plugin-name": false, ...etc...}
I guess it exposes some internals we might now want to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to make it json per your example (i.e. not just for curling humans).
It does expose internals, so might want to allow users to disable it.
Might be nice to add for when a human runs a curl
…On Tue, 26 Feb 2019, 21:26 John Belamaric, ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In plugin/ready/ready.go
<#2616 (comment)>:
> + }
+
+ rd.Lock()
+ rd.ln = ln
+ rd.mux = http.NewServeMux()
+ rd.done = true
+ rd.Unlock()
+
+ rd.mux.HandleFunc("/ready", func(w http.ResponseWriter, _ *http.Request) {
+ ok, todo := plugs.Ready()
+ if ok {
+ w.WriteHeader(http.StatusOK)
+ io.WriteString(w, "OK")
+ return
+ }
+ log.Infof("Still waiting on: %q", todo)
Is there a reason not to also write this to the body of the response? A
500 error can still have a body. Something like {"plugin-name": false,
...etc...}
I guess it exposes some internals we might now want to.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2616 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAVkW5sydASxn3iO3rQXnu7XqDP5e2hKks5vRaZygaJpZM4bQPIM>
.
|
[ Quoting <notifications@github.com> in "Re: [coredns/coredns] Add *ready* p..." ]
+1 to make it json per your example (i.e. not just for curling humans).
It does expose internals, so might want to allow users to disable it.
Thanks, but I think both suggestions are taking this a bit too far.
|
This is now fully ready. PTAL The proposed changes from @fturib will be done in a seperate PR for: health, prometheus and this plugin. |
/lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM by johnbelamaric
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>
quay.io is broken sigh |
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>
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>
Add a ready plugin that allows plugin to signal when they are ready.
This uses simple functions defined in the ready plugin; RegisterPlugin
and Signal.
Add README.md and tests moduled on the health plugin; which will be
relegated to just providing process health. In similar vein to health
this is a process wide setting meaning it will need to include all
plugins for all server block when signalling readiness.
During startup it block forever, while displaying the status every
second:
This was started with this Corefile
Both erratic plugins are reporting readiness.
Signed-off-by: Miek Gieben miek@miek.nl
See #2611 and #2547