Skip to content
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

[release-4.18] nrop: controller: get rtestate from cluster just once #1145

Merged
merged 1 commit into from
Jan 8, 2025

Conversation

ffromani
Copy link
Member

@ffromani ffromani commented Jan 8, 2025

We used to get the current cluster state both when attempting to sync the machine config state in the OpenShift flow, and when attempting to sync the RTE daemonsets in both flows.

Due to the way rtestate.FromClient works, we end up reading the full cluster state twice in the openshift flow, which is unnecessary and wasteful.

The fix is to get the cluster state once in the higher level function and pass the state in the specific reconcile step functions. The machine config and daemonset functions touch not overlapping objects (bar bugs) so sharing the state between them is expected to be fine.

In other words, we happen to fetch the state twice most likely because of oversight, not because a deliberate decision about data sharing/unsharing (which, should that be the case, would need some extra refactoring and more explicit code).

Signed-off-by: Francesco Romani [email protected]
(cherry picked from commit 835a9a8)

We used to get the current cluster state both when
attempting to sync the machine config state in the OpenShift flow,
and when attempting to sync the RTE daemonsets in both flows.

Due to the way `rtestate.FromClient` works, we end up
reading the full cluster state twice in the openshift flow,
which is unnecessary and wasteful.

The fix is to get the cluster state once in the higher level
function and pass the state in the specific reconcile step functions.
The machine config and daemonset functions touch not overlapping
objects (bar bugs) so sharing the state between them is expected
to be fine.

In other words, we happen to fetch the state twice most likely
because of oversight, not because a deliberate decision about
data sharing/unsharing (which, should that be the case, would need
some extra refactoring and more explicit code).

Signed-off-by: Francesco Romani <[email protected]>
(cherry picked from commit 835a9a8)
@openshift-ci openshift-ci bot requested review from shajmakh and swatisehgal January 8, 2025 09:41
Copy link
Contributor

openshift-ci bot commented Jan 8, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ffromani

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 8, 2025
Copy link
Collaborator

@swatisehgal swatisehgal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jan 8, 2025
@openshift-merge-bot openshift-merge-bot bot merged commit 7a2abe5 into release-4.18 Jan 8, 2025
15 checks passed
@ffromani ffromani deleted the rtestate-fromclient-once-4.18 branch January 9, 2025 10:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants