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
[virt-operator]: always deploy the outdated VMI workload alert #9988
Conversation
/hold |
the motivation is to eliminate redundant kubevirt deployment calculations and re-deployment. The alternative to this approach is to inject/remove the alert in virt-operator reconciler logic but I think it will add a boiler-plate code. Signed-off-by: enp0s3 <ibezukh@redhat.com>
3cb24b0
to
61a98f1
Compare
/unhold |
/retest-required |
/cc @vladikr |
/retest-required |
/cc |
/cc |
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.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jean-edouard The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
/retest-required |
Signed-off-by: enp0s3 ibezukh@redhat.com
I don't see any harm in permanent deployment of that alert. The evaluation of
kubevirt_vmi_outdated_count != 0
will remain false even the metric is stale, so I don't see any risk of false positives here.
What this PR does / why we need it:
In the current situation if we configure a workload update method in the Kubevirt CR it will
cause re-deployment of all the virt-components. That is because adding a method will populate the
additionalProperties
map, which in turn cause changes in kubevirt deployment config digest.We can change the logic and to inject the alert in the virt-operator sync loop in the reconciler, but
I think it is a redundant considering the fact the deployment of this alert anyway won't cause any
harm.
Release note: