Skip to content
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

Merged
merged 1 commit into from
Mar 7, 2019
Merged

Add *ready* plugin #2616

merged 1 commit into from
Mar 7, 2019

Conversation

miekg
Copy link
Member

@miekg miekg commented Feb 25, 2019

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:

2019-02-25T16:09:02.168Z [INFO] plugin/ready: Waiting on 2/2: erratic
2019-02-25T16:09:03.168Z [INFO] plugin/ready: All plugins signal readiness
.:1053
bla.:1053
2019-02-25T16:09:03.168Z [INFO] CoreDNS-1.3.1
2019-02-25T16:09:03.168Z [INFO] linux/amd64, go1.11.4,
CoreDNS-1.3.1
linux/amd64, go1.11.4,
^C[INFO] SIGINT: Shutting down

This was started with this Corefile

. {
    erratic
    whoami
    ready
}

bla {
    erratic
    whoami
}

Both erratic plugins are reporting readiness.

Signed-off-by: Miek Gieben miek@miek.nl

See #2611 and #2547

@corbot corbot bot requested a review from greenpau February 25, 2019 16:16
@corbot
Copy link

corbot bot commented Feb 25, 2019

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 /OWNERS) for a review.

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)

Copy link
Contributor

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)

@miekg
Copy link
Member Author

miekg commented Feb 25, 2019 via email

@codecov-io
Copy link

codecov-io commented Feb 26, 2019

Codecov Report

Merging #2616 into master will increase coverage by 0.1%.
The diff coverage is 66.33%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
plugin/erratic/ready.go 0% <0%> (ø)
plugin/ready/list.go 100% <100%> (ø)
plugin/ready/setup.go 47.61% <47.61%> (ø)
plugin/ready/ready.go 78.12% <78.12%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7ffa4f1...30e326c. Read the comment docs.

@chrisohaver
Copy link
Member

Thanks for adding this, although, I was thinking we'd just need report readiness (and not actually block serving until all plugins are ready).

@miekg
Copy link
Member Author

miekg commented Feb 26, 2019

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

@miekg
Copy link
Member Author

miekg commented Feb 26, 2019

ok, reworked it to;
a) Address Chris' comment
b) make it local to a server block

io.WriteString(w, "OK")
return
}
log.Infof("Still waiting on: %q", todo)
Copy link
Member

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.

Copy link
Member

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.

@miekg
Copy link
Member Author

miekg commented Feb 26, 2019 via email

@miekg
Copy link
Member Author

miekg commented Feb 27, 2019 via email

@miekg
Copy link
Member Author

miekg commented Mar 1, 2019

This is now fully ready. PTAL

The proposed changes from @fturib will be done in a seperate PR for: health, prometheus and this plugin.

@johnbelamaric
Copy link
Member

/lgtm

Copy link

@corbot corbot bot left a 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>
@miekg
Copy link
Member Author

miekg commented Mar 7, 2019

quay.io is broken sigh

@miekg miekg merged commit db0b16b into master Mar 7, 2019
@corbot corbot bot deleted the ready branch March 7, 2019 20:35
@miekg miekg mentioned this pull request Mar 7, 2019
Jason-ZW pushed a commit to rancher/coredns that referenced this pull request Apr 17, 2019
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>
dna2github pushed a commit to dna2fork/coredns that referenced this pull request Jul 19, 2019
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants