-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
using more sensible consul blocking query to detect health check changes #1241
Conversation
Is it going to a release any time soon? |
@emilevauge, @rokka-n |
Can we expect this in 1.2.0? |
@jzvelc we'd have to consider the issue that this PR fixes to be critical enough to warrant being merged into the 1.2 release branch, which has already reached candidate 2 status at this time. @emilevauge thoughts? |
Please merge this, as we really need it asap! This is critical for anyone using traefik with consul, since services that have healthchecks won't appear in traefik... |
Unit and integration tests needed for this pr. |
There are (at least) two routes to add unit tests here:
I'm leaning towards 2. if the effort is reasonable. I haven't looked at the integration tests yet. |
@vholovko It would be great to get this into v1.2. Could you rebase your PR against v1.2 branch? Do you think adding unit/integration tests on this is doable anytime soon? |
provider/consul_catalog.go
Outdated
data, meta, err := catalog.Services(opts) | ||
// Listening to changes that leads to `passing` state or degrades from it. | ||
// The call is used just as a trigger for further actions (intentionally there is no interest in the received data). | ||
_, meta, err := health.State("passing", opts) |
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.
@vholovko I still have a doubt on this implementation in case we register services in Consul without healthcheck. Will these services trigger this listener ?
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.
@emilevauge
It is a valid point!
I can confirm that trigger wont work in this situation. Should rework it to listen both the catalog.Services
and health.State
at the same time
We are going to release v1.2 soon. Do you want your PR to be in that release @vholovko ? |
Hi @emilevauge, Apparently it doesn't work for case with services without health check defined. |
@vholovko ping ? |
Implemented version that should support both kinds of services: with health checks and without. However, I have an alternative draft proposal slightly different in terms of implementation, where the only clean way to test things was to use interfaces. consul_catalog.go It can look ugly at first glance but it allows legal and not hacky approach for mocking struct methods inside tests via Interfacing. The one and only issue here is that Would be glad to receive any possible help for testing original 9501821 commit. Thanks |
@vholovko the code still checks only for passing health state, which would work just fine for services that have health checks defined, for those that don't the checks would only be serfHealth by default.. would there be a refresh and a change in index on the health state endpoint in such a case ? unless the node goes down or comes back up. |
@venkataramanr |
thanks @vholovko for responding. SerfHeath does appear on the health endpoint, yet, unless there is a change in the agent's health status ( which is serf health ) would there be an update to the index ? |
@vholovko Can you change the target branch of this PR from |
5e2e3a0
to
3f6ad4e
Compare
3f6ad4e
to
6fd40db
Compare
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 @vholovko
LGTM
Possible fix for #1107
Using health.State only as a trigger for further actions.