fix: Increase reconcile metric only if SSP CR was not changed

[akrejcir]

What this PR does / why we need it:
The metric kubevirt_ssp_common_templates_restored_total should be increased if user changes a template and the operator restores it back to what it should be.

If the SSP CR is changed, for example one of the labels that are propagated to the templates are changed, then the reconciliation should not increase the metric.

Fixes: https://issues.redhat.com/browse/CNV-39928

Release note:

None

[akrejcir]

/cc @0xFelix @machadovilaca @ksimon1

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[0xFelix]

/approve

Looks good to me. But allow me a question, is there really a benefit to exposing this metric at all?

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 0xFelix

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:

• OWNERS [0xFelix]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[akrejcir]

/approve

Looks good to me. But allow me a question, is there really a benefit to exposing this metric at all?

I think it is a question for @machadovilaca or @sradco .

[sradco]

/approve

Looks good to me. But allow me a question, is there really a benefit to exposing this metric at all?

I think it is a question for @machadovilaca or @sradco .

This metric is used for an alert.

[0xFelix]

/approve
Looks good to me. But allow me a question, is there really a benefit to exposing this metric at all?

I think it is a question for @machadovilaca or @sradco .

This metric is used for an alert.

Let me rephrase, is there a benefit to having that alert?

[sradco]

/approve
Looks good to me. But allow me a question, is there really a benefit to exposing this metric at all?

I think it is a question for @machadovilaca or @sradco .

This metric is used for an alert.

Let me rephrase, is there a benefit to having that alert?

This is not for me or @machadovilaca to decide.
It up to your team.

From what I understand the alert is educational, But I see it has "warning" severity.
Is that the correct severity for it?

I think it should be "info" if you keep it, since it doesn't impact the SSP operator functionality or even puts it at risk of losing functionality. https://github.com/kubevirt/monitoring/blob/main/docs/runbooks/SSPCommonTemplatesModificationReverted.md

[0xFelix]

@sradco Thanks for the clarification. I don't see a benefit in this alert to be honest. We should reevaluate the need for it. Also, you are right, it should be of severity info.

[akrejcir]

I've opened a new issue for us to reevaluate which metrics are needed: #956

[akrejcir]

Can you please take a look, when you have a moment?

/cc @ksimon1 @jcanocan

[jcanocan]

/lgtm

[akrejcir]

/cherry-pick release-v0.19

[kubevirt-bot]

@akrejcir: new pull request created: #959

In response to this:

/cherry-pick release-v0.19

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.