OCPBUGS-41485: Update MCD Log Output to Clarify No Configuration Change

[dkhater-redhat]

- What I did
Implemented the getDesiredName method in stateAndConfigs to provide clear logging for no configuration changes.

- How to verify it

1. Ensure that the mcd logs reflect the correct state when no update is necessary.
2. Check that the log message indicates whether the configuration was already at the desired state or if an update was applied.
3. Review the output of the getDesiredName to confirm that it accurately reflects the desired MachineConfig and associated image.

- Description for the changelog
Implemented the getDesiredName method in stateAndConfigs to provide clear logging for no configuration changes.

[openshift-ci-robot]

@dkhater-redhat: This pull request references Jira Issue OCPBUGS-41485, which is invalid:

• expected the bug to target the "4.18.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

- What I did
Implemented the getDesiredName method in stateAndConfigs to provide clear logging for no configuration changes.

- How to verify it

1. Ensure that the mcd logs reflect the correct state when no update is necessary.
2. Check that the log message indicates whether the configuration was already at the desired state or if an update was applied.
3. Review the output of the getDesiredName to confirm that it accurately reflects the desired MachineConfig and associated image.

- Description for the changelog
Implemented the getDesiredName method in stateAndConfigs to provide clear logging for no configuration changes.

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 openshift-eng/jira-lifecycle-plugin repository.

[dkhater-redhat]

/retest-required

[dkhater-redhat]

/retest-required

[openshift-ci]

@dkhater-redhat: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-vsphere-ovn-upi	0999aa2	link	false	/test e2e-vsphere-ovn-upi
ci/prow/e2e-vsphere-ovn-upi-zones	0999aa2	link	false	/test e2e-vsphere-ovn-upi-zones
ci/prow/e2e-gcp-op-techpreview	0999aa2	link	false	/test e2e-gcp-op-techpreview
ci/prow/e2e-vsphere-ovn-zones	0999aa2	link	false	/test e2e-vsphere-ovn-zones

Full PR test history. Your PR dashboard.

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-sigs/prow repository. I understand the commands that are listed here.

[dkhater-redhat]

/test e2e-gcp-op

[sergiordlr]

@dkhater-redhat Hello! We have problems installing the images created for the PRs (all the PRs not only this one). Nevertheless, nightly builds are installing without problems. Could you please merge this PR? we will test it post-merge in the nightly build. Thanks!!

We don't add the qe-approved label since it will verified post-merge.

[yuqi-zhang]

/jira refresh
/lgtm

[openshift-ci-robot]

@yuqi-zhang: This pull request references Jira Issue OCPBUGS-41485, which is invalid:

• expected the bug to be in one of the following states: NEW, ASSIGNED, POST, but it is ON_QA instead

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

/jira refresh
/lgtm

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dkhater-redhat, yuqi-zhang

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 [dkhater-redhat,yuqi-zhang]

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

[sergiordlr]

Hello! I'm not sure about how to reproduce the issue.

In the jira ticket it is said that when we restart the node the MCDs are showing a certain log. But when we manually restart a node MCDs do not change their logs.

Instead, it seems that the log that we can find in the jira ticket corresponds to deleting the MCD pod. At least when we delete a MCD the log of the new MCD is the same as the one posted in the jira ticket. If that's the case the problem is not solved and the log still reports

I0930 10:45:47.525872    8838 daemon.go:2244] Completing update to target MachineConfig: rendered-worker-perf-canary-57050ba3effa775a3a8b449d7724d926

Instead of

No update required

Please, could you share more information about how to reproduce this issue?

When we remove a MCD, should the logs reflect that no change was actually done too?

[djoshy]

Please, could you share more information about how to reproduce this issue?

When we remove a MCD, should the logs reflect that no change was actually done too?

I think you're on the right track. The original bug (that this bug was "spun off" from) was filed because one of the nodes went through an uncontrolled reboot(so the pod did not get to safely terminate). Deleting the pod should have a similar effect.

[sergiordlr]

Hello @djoshy and @dkhater-redhat !!
The log that we get when we remove the MCD is not showing the expected messages. It continues showing that it applied a configuration when it didn't.

I0930 10:45:47.525872    8838 daemon.go:2244] Completing update to target MachineConfig: rendered-worker-perf-canary-57050ba3effa775a3a8b449d7724d926

Since the previous comment this scenario should show the No update required, configuration is already at desired state message instead.