-
Notifications
You must be signed in to change notification settings - Fork 486
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
Added proposal for remediation history #567
Conversation
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.
@jewzaam @JoelSpeed Thanks for your review! Please check my comments / improvements.
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
3f6865a
to
01afb4d
Compare
Before we go on discussing names of timestamps on outdated code snippets... is this fine for everyone?
|
Signed-off-by: Marc Sluiter <msluiter@redhat.com>
Signed-off-by: Marc Sluiter <msluiter@redhat.com>
Signed-off-by: Marc Sluiter <msluiter@redhat.com>
Signed-off-by: Marc Sluiter <msluiter@redhat.com>
Signed-off-by: Marc Sluiter <msluiter@redhat.com>
01afb4d
to
44322ae
Compare
Signed-off-by: Marc Sluiter <msluiter@redhat.com>
@JoelSpeed anything holding this back from being merged? |
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.
As I understand it, a machine will get detected, the remediation event will be added, that event will then be updated as time progresses. What happens if that remediation event never actually causes a remediation, does the status then look like we lost track of it?
Do we need to have a third Type
that is called recovered
and then if we detect a machine that we thought would go unhealthy, mark the event as recovered?
(If we go down this avenue, how does this work when nodes are starting, since they appear unhealthy at first?)
Has there been any discussion with the upstream community about this type of enhancement, would be good to have this feature upstreamed as well
…e field Signed-off-by: Marc Sluiter <msluiter@redhat.com>
Renamed |
Signed-off-by: Marc Sluiter <msluiter@redhat.com>
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
/remove-lifecycle rotten |
/remove-lifecycle rotten |
Inactive enhancement proposals go stale after 28d of inactivity. See https://github.com/openshift/enhancements#life-cycle for details. Mark the proposal as fresh by commenting If this proposal is safe to close now please do so with /lifecycle stale |
Stale enhancement proposals rot after 7d of inactivity. See https://github.com/openshift/enhancements#life-cycle for details. Mark the proposal as fresh by commenting If this proposal is safe to close now please do so with /lifecycle rotten |
Rotten enhancement proposals close after 7d of inactivity. See https://github.com/openshift/enhancements#life-cycle for details. Reopen the proposal by commenting /close |
@openshift-bot: Closed this PR. In response to this:
Instructions 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/test-infra repository. |
We propose to track a limited history of remediations and showing it in the UI in order to allow admins to detect recurring node problems easier.
/cc @beekhof @JoelSpeed @michaelgugino @enxebre