-
Notifications
You must be signed in to change notification settings - Fork 1.4k
🐛 Remove generated names from error messages to reduce reconciliation #5971
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
🐛 Remove generated names from error messages to reduce reconciliation #5971
Conversation
@@ -269,7 +269,7 @@ func (r *Reconciler) reconcileMachineHealthCheck(ctx context.Context, current, d | |||
|
|||
log.Infof("Creating %s", tlog.KObj{Obj: desired}) | |||
if err := r.Client.Create(ctx, desired); err != nil { | |||
return errors.Wrapf(err, "failed to create %s", tlog.KObj{Obj: desired}) | |||
return createError(err, desired) |
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.
for sake of consistency, should this be
return createError(err, desired) | |
errors.Wrapf(err, "failed to create %s", desired.Kind) |
same below/in other places where we are returning createError without wrapping
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 think we have to decide if we want to add the "failed to create" here or in the func.
I think it could be better to do it here (as we can provide additional context which is needed in some cases). But then the createError/apiErrorWithoutObjectName should focus on sanitizing the StatusError and not also wrap it with failed to create ...
.
P.S. for additional context I made some proposals here: #5945 (comment)
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.
For now I'd prefer to keep the create specific information here - I don't think this is more than a single-use function. The additional info can be added by wrapping errors I think - e.g. where the MachineDeployment object kind is added.
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.
Sure, give it a try.
@@ -269,7 +269,7 @@ func (r *Reconciler) reconcileMachineHealthCheck(ctx context.Context, current, d | |||
|
|||
log.Infof("Creating %s", tlog.KObj{Obj: desired}) | |||
if err := r.Client.Create(ctx, desired); err != nil { | |||
return errors.Wrapf(err, "failed to create %s", tlog.KObj{Obj: desired}) | |||
return createError(err, desired) |
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 think we have to decide if we want to add the "failed to create" here or in the func.
I think it could be better to do it here (as we can provide additional context which is needed in some cases). But then the createError/apiErrorWithoutObjectName should focus on sanitizing the StatusError and not also wrap it with failed to create ...
.
P.S. for additional context I made some proposals here: #5945 (comment)
93c74f0
to
4a72596
Compare
} | ||
|
||
// Replace the statusError message with the constructed message. | ||
statusError.ErrStatus.Message = fmt.Sprintf("failed to create %s", out) |
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.
statusError.ErrStatus.Message = fmt.Sprintf("failed to create %s", out) | |
statusError.ErrStatus.Message = fmt.Sprintf("failed to create: %s", out) |
nit, usually errors are concatenated with a colon as separator
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.
Should we only add out
if it's not empty? Currently the error would have a trailing space in that case
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 out is empty at this point the error isn't going to be make any sense regardless I think - should we instead return the error on L750 if there's nothing in out?
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.
Yes!
4a72596
to
ed4d92a
Compare
9423b3b
to
bb599a0
Compare
bb599a0
to
9be7337
Compare
Signed-off-by: killianmuldoon <[email protected]>
9be7337
to
78eec8e
Compare
Thanks @killianmuldoon for sorting out this problem |
@killianmuldoon /lgtm |
/cherry-pick release-1.1 As it's a problematic bug we should include it in the v1.1 release |
@sbueringer: once the present PR merges, I will cherry-pick it on top of release-1.1 in a new PR and assign it to you. 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/test-infra repository. |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini 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 |
@sbueringer: new pull request created: #5992 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/test-infra repository. |
Signed-off-by: killianmuldoon [email protected]
Sanitize error messages in the topology controller to prevent reported errors from causing reconciliation.
This is a Work In Progress and should not be merged.
Fixes #5945