Emit an event when the result of a probe for a container changes#135401
Conversation
|
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
Hi @Maxim-Durand. Thanks for your PR. I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Maxim-Durand The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
89f9d50 to
bdde2c3
Compare
|
Force pushed to rebase from latest master |
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/sig node
What type of PR is this?
/kind feature
/kind api-change
What this PR does / why we need it:
This PR introduces a new event that is emitted by the probe worker when the result of the probe changes. End-users can watch this new event to learn when their probes entered the Sucess or Failure state and in the case of Failure they gain some contextual information in the form of the output from the last probe.
Which issue(s) this PR is related to:
Fixes #115823 by dealing with the lack of information on when a probe fails (as users can now just look at this event)
Special notes for your reviewer:
This is revival of #115963 as requested in #115823 (comment)
The original PR passed most of the review process but wasn't kept updated enough to merge in the end.
This PR is a faithful copy of the original one on top of the latest master branch (the original PR being 2 years old).
Does this PR introduce a user-facing change?
Yes