-
Notifications
You must be signed in to change notification settings - Fork 169
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
Propagate errors of ARO MachineHealthCheckController to ARO Operator #3177
Propagate errors of ARO MachineHealthCheckController to ARO Operator #3177
Conversation
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.
Looks good so far, thanks for your work on this. One bug to fix. The last thing I think is to add some E2E tests for validating the conditions of the operator during each test execution.
As a final super-nit, there are quite a few newlines added that I don't think add value (at least 6). It's likely best to delete those to reduce the diff.
err := r.client.Get(ctx, types.NamespacedName{Name: arov1alpha1.SingletonClusterName}, instance) | ||
// Reconcile watches MachineHealthCheck objects, and if any changes, | ||
// reconciles the associated ARO MachineHealthCheck object | ||
|
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.
I'm not 100% sure, but I think this extra newline might mess up godoc on this function.
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.
So should I just remove the blank lines or the comment also? Because other ones are just comments on it for code readability. I can remove them anyways we have a proper doc on those available under readme.md.
pkg/operator/controllers/machinehealthcheck/machinehealthcheck_controller.go
Show resolved
Hide resolved
Addressed all coments just left with E2E
pkg/operator/controllers/machinehealthcheck/machinehealthcheck_controller_test.go
Outdated
Show resolved
Hide resolved
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.
Overall, LGTM. I think removing the MHC
prefix changes would reduce the diff and keep this controller in-line with other controller standard patterns. Nice work!
pkg/operator/controllers/machinehealthcheck/machinehealthcheck_controller.go
Outdated
Show resolved
Hide resolved
Removed the MHC Prefix. |
Done. |
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.
Logic and tests are looking great! I found a few more breaks from convention with a few struct/function names. Keeping our controllers and properties named consistently makes it easier to work on each of them. Excellent work, thanks Mohammed!
pkg/operator/controllers/machinehealthcheck/machinehealthcheck_controller.go
Outdated
Show resolved
Hide resolved
I'll take care of that part you mentioned. Thank you very much. |
pkg/operator/controllers/machinehealthcheck/machinehealthcheck_controller.go
Outdated
Show resolved
Hide resolved
pkg/operator/controllers/machinehealthcheck/machinehealthcheck_controller.go
Outdated
Show resolved
Hide resolved
pkg/operator/controllers/machinehealthcheck/machinehealthcheck_controller.go
Outdated
Show resolved
Hide resolved
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.
Looks good, there are just some minor fixups to make, awesome work!
pkg/operator/controllers/machinehealthcheck/machinehealthcheck_controller.go
Outdated
Show resolved
Hide resolved
pkg/operator/controllers/machinehealthcheck/machinehealthcheck_controller.go
Outdated
Show resolved
Hide resolved
…per message for setProgressing use case
df83a40
to
bf8b8d9
Compare
Done. |
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.
This is looking really clean! Only one comment based on our discussion. Thanks for your hard work on this!
if !instance.Spec.OperatorFlags.GetSimpleBoolean(managed) { | ||
r.SetProgressing(ctx, "Not MHC Managed for cluster maintenance purpose.") |
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.
Leaving a comment here based on our discussion yesterday, it seems like Progressing
isn't necessary here. We should remove the SetProgresing
and ClearProgressing
calls.
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.
Agree here. Progressing
is not required and will solve a few of the other requested changes on this PR by removing it.
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.
Removed those calls.
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.
LGTM, just need all CI/E2E green :)
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.
Nice work!
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.
LGTM Thanks for this!
…zure#3177) * Propagate errors of ARO MachineHealthCheckController to ARO Operator
Which issue this PR addresses:
Fixes - https://issues.redhat.com/browse/ARO-3256
What this PR does / why we need it:
Aggregates errors from the MachineHealthCheck controller and propagates to the ARO Operator.
Test plan for issue:
As of now I think it must pass the local test cases after spinning up a test cluster and if case scenarios falls under the test conditions defined in code then error propagation will happen.
Is there any documentation that needs to be updated for this PR?
None that I'm aware of.