-
Notifications
You must be signed in to change notification settings - Fork 14
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
objstate: rte: isolate platform-specific code #1114
Conversation
ccb669d
to
a78f266
Compare
/cc @Tal-or |
/hold need to merge more urgent changes before |
@@ -45,6 +45,13 @@ const ( | |||
HyperShiftNodePoolLabel = "hypershift.openshift.io/nodePool" | |||
) | |||
|
|||
// TODO: ugly name. At least it's only internal | |||
type rteHelper interface { |
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.
StateFinder
?
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.
thought about it but it reads poorly with the method names, which in turn are called this way to suggest where the helper is supposed to be used (in FromClient
and State
functions)
@@ -558,8 +558,8 @@ func (r *NUMAResourcesOperatorReconciler) syncNUMAResourcesOperatorResources(ctx | |||
return nil | |||
} | |||
|
|||
existing := rtestate.FromClient(ctx, r.Client, r.Platform, r.RTEManifests, instance, trees, r.Namespace) | |||
for _, objState := range existing.State(r.RTEManifests, processor, annotations.IsCustomPolicyEnabled(instance.Annotations)) { | |||
existing := rtestate.FromClient(ctx, r.Client, r.Platform, r.RTEManifests, instance, trees, r.Namespace).WithManifestsUpdater(processor) |
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.
If we're going with a builder pattern (AKA method-changing) then let's do it for the additional args as well
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.
still not sure about going this route, but will take this into consideration
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.
the last commit should clarify why I'm keeping the current approach
extract helper to update the state from either NodeGroups or MachineConfigPools into helpers. The goal here is to isolate this code to make the main calling functions more targeted and to unblock future refactoring. Signed-off-by: Francesco Romani <[email protected]>
extract helper to fetch the state from either NodeGroups or MachineConfigPools into helpers. The goal here is to isolate this code to make the main calling functions more targeted and to unblock future refactoring. Add helpers to inject parameters. This helps making the objectstate flavours all consistent with each other; previously `rte` was the outlier and the only variant with extra parameters. This require the constructor function to return a pointer to a struct (not a struct). Update all the variants for consistency. Signed-off-by: Francesco Romani <[email protected]>
a78f266
to
d9488d2
Compare
related to: #1142 |
/hold cancel work here is done, pending only review and validation |
move helpers in per-mode files. This is meant to keep the filesize at bay and to enable future code extraction. No intended change in behavior. Signed-off-by: Francesco Romani <[email protected]>
the helpers we extracted in previous commits still share some state; pack them in a struct, which makes also nicer to consume them from the caller site(s), acting almost like a type. In the (far?) future, when we will move completely to nodegroups (if ever), this code should be dissolved back in the callers. Signed-off-by: Francesco Romani <[email protected]>
We used to get the current cluster state both when attempting to sync the machine config state in the OpenShift flow, and when attemptiny 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]>
e341b37
to
835a9a8
Compare
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ffromani, Tal-or 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 |
/cherry-pick release-4.18 |
@ffromani: once the present PR merges, I will cherry-pick it on top of 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-sigs/prow repository. |
@ffromani: #1114 failed to apply on top of branch "release-4.18":
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-sigs/prow repository. |
fair enough. Let's make a more targeted fix for 4.18 |
isolate per-platform specific code in their own types and source code, to reduce the clutter without intentional changes of behavior.
The idea is to gradually move towards full isolation and containment of the platform-specific code, and this change is a step in that direction.
Actually, we dopn't really care about the platform but rather about how we find the nodes, but the method (poolName vs machineconfigpool) is still tied to the platform, hence the ambiguity.
In the long run we want to support only the newer pool approach introduced with HCP.