Shorten UpdateNodeLabelsAndRecordEvents function in nmc_reconciler.go

[TomerNewman]

Summary

Today, the UpdateNodeLabelsAndRecordEvents function has around 100 lines of code. This commit aims to enhance its readability and maintainability by using helper functions, thereby reducing its total length. Additionally, adding unit tests that covers the new helper functions.

[k8s-ci-robot]

Hi @TomerNewman. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[netlify]

✅ Deploy Preview for kubernetes-sigs-kmm ready!

Name	Link
🔨 Latest commit	fe5d5d8
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-kmm/deploys/6693e64509088d0008253968
😎 Deploy Preview	https://deploy-preview-850--kubernetes-sigs-kmm.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[TomerNewman]

/assign @yevgeny-shnaidman

[yevgeny-shnaidman]

/ok-to-test

[yevgeny-shnaidman]

It looks good to me , but i have another suggestion:
most of the code of UpdateNodeLabelsAndRecordEvents function deals with preparing the labels for the node. What if we define another helper interface, that will handle that preparation? This way we can unit-test the UpdateNodeLabelsAndRecordEvents properly and in addition test the labels preparation thoroughly also, since it will be in a different interface. @ybettan , @TomerNewman , what do you think? Or is it an overkill?

[TomerNewman]

It looks good to me , but i have another suggestion: most of the code of UpdateNodeLabelsAndRecordEvents function deals with preparing the labels for the node. What if we define another helper interface, that will handle that preparation? This way we can unit-test the UpdateNodeLabelsAndRecordEvents properly and in addition test the labels preparation thoroughly also, since it will be in a different interface. @ybettan , @TomerNewman , what do you think? Or is it an overkill?

so it should be in a different package? maybe in internal->utils->kmmlabels.go?

[yevgeny-shnaidman]

It looks good to me , but i have another suggestion: most of the code of UpdateNodeLabelsAndRecordEvents function deals with preparing the labels for the node. What if we define another helper interface, that will handle that preparation? This way we can unit-test the UpdateNodeLabelsAndRecordEvents properly and in addition test the labels preparation thoroughly also, since it will be in a different interface. @ybettan , @TomerNewman , what do you think? Or is it an overkill?

so it should be in a different package? maybe in internal->utils->kmmlabels.go?

No, it can be in the same package, for example like PodManager interface

[TomerNewman]

It looks good to me , but i have another suggestion: most of the code of UpdateNodeLabelsAndRecordEvents function deals with preparing the labels for the node. What if we define another helper interface, that will handle that preparation? This way we can unit-test the UpdateNodeLabelsAndRecordEvents properly and in addition test the labels preparation thoroughly also, since it will be in a different interface. @ybettan , @TomerNewman , what do you think? Or is it an overkill?

so it should be in a different package? maybe in internal->utils->kmmlabels.go?

No, it can be in the same package, for example like PodManager interface

I'm on it, give me thumbs up to the comment to confirm and I'll push the changes

[ybettan]

It looks good to me , but i have another suggestion:
most of the code of UpdateNodeLabelsAndRecordEvents function deals with preparing the labels for the node. What if we define another helper interface, that will handle that preparation? This way we can unit-test the UpdateNodeLabelsAndRecordEvents properly and in addition test the labels preparation thoroughly also, since it will be in a different interface. @ybettan , @TomerNewman , what do you think? Or is it an overkill?

I think that the parts that add/remove labels from the nodes should be part of the new node interface as long as the label is passed as a parameter.

For other cases, I definitely think we should create another interface and I would also somehow take into consideration internal->utils->kmmlabels.go as it is serving a similar purpose.

[yevgeny-shnaidman]

It looks good to me , but i have another suggestion:
most of the code of UpdateNodeLabelsAndRecordEvents function deals with preparing the labels for the node. What if we define another helper interface, that will handle that preparation? This way we can unit-test the UpdateNodeLabelsAndRecordEvents properly and in addition test the labels preparation thoroughly also, since it will be in a different interface. @ybettan , @TomerNewman , what do you think? Or is it an overkill?

I think that the parts that add/remove labels from the nodes should be part of the new node interface as long as the label is passed as a parameter.

For other cases, I definitely think we should create another interface and I would also somehow take into consideration internal->utils->kmmlabels.go as it is serving a similar purpose.

I thought about kmmlabels, but its main purpose is to define the labels, to to manipulate what and when should go to wihat node

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 97.46835% with 2 lines in your changes missing coverage. Please review.

Project coverage is 71.95%. Comparing base (fa23a9b) to head (fe5d5d8).
Report is 80 commits behind head on main.

Files	Patch %	Lines
internal/controllers/nmc_reconciler.go	96.61%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #850      +/-   ##
==========================================
- Coverage   79.09%   71.95%   -7.14%     
==========================================
  Files          51       66      +15     
  Lines        5109     4522     -587     
==========================================
- Hits         4041     3254     -787     
- Misses        882     1073     +191     
- Partials      186      195       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ybettan]

This comment is for purpose learning only as it is not directly related to your PR.

This is not a great validation. The description of the spec is should complete all the reconcile functions and return combined error, therefore, the validation should be to (first return different error messages and then) validate that the combined error contain each one of the error messages of the individual errors.

[TomerNewman]

@ybettan so in that case, I can add validations that each expected error should be in err, to add it to the PR?

[ybettan]

You don't have to add it to the PR so we can merge it faster. You can fix it in a future PR if you like. But to answer your question, the answer is YES.

One way to check it is like this example:

kernel-module-management/internal/registry/registry_test.go

Line 57 in c44a5e8

Expect(err.Error()).To(ContainSubstring("failed to get pull options for image"))

[ybettan]

/approve
/assign @yevgeny-shnaidman

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: TomerNewman, ybettan

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 [ybettan]

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

[yevgeny-shnaidman]

/lgtm