-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
Fix EnsureAdminClusterRoleBindingImpl error handling #122893
Fix EnsureAdminClusterRoleBindingImpl error handling #122893
Conversation
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
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.
EnsureAdminClusterRoleBindingImpl assumed that the client Create() call would return nil on error, but that's not how the real clients work; only the fake clients work that way. 😖
yikes.
probably? Also, the code is new in 1.29 but I don't know if that makes it /kind regression or if it's a bug in a new feature
i think we can go without a release note, but this seems like it should be backported to 1.29. it's new code in 1.29, so no /kind regression
. please send the cherry pick if you could, i will be OOO but i can lgtm/approve,
FWIW the unit test probably would have caught this bug in one of the other sub-tests if it checked the error text rather than just checking "any error" vs "no error"... (Though I recognize that people have differing opinions on whether unit tests should check for specific error text...)
returning always nil
on error seems fine to me.
no unit tests updates are needed here in this PR?
/approve
@@ -642,6 +642,7 @@ func EnsureAdminClusterRoleBindingImpl(ctx context.Context, adminClient, superAd | |||
clusterRoleBinding, | |||
metav1.CreateOptions{}, | |||
); err != nil { | |||
crbResult = nil |
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 almost feels like a bug or a "miss-design" in client-go.
in go stdlib commonly if err != nil, everything else is nil or 0 value.
returning a zeroed struct is not so common.
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.
Yeah; I would have changed the real clients to return nil rather than changing the fake clients to return non-nil but that would presumably break real code...
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: danwinship, neolit123 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 |
/release-note-none |
The code assumed Create() returned nil on error, but that's only true for the fake clients in unit tests.
c34349b
to
b18caee
Compare
No, because we're just going from "crbResult is nil because FakeClient.Create() returned nil on error" to "crbResult is nil because we explicitly set it to nil ourselves (and also FakeClient.Create() returned nil anyway but we're pretending it didn't)". |
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
LGTM label has been added. Git tree hash: 2f65984294686bd80386d1f0aee44ab003832fdf
|
What type of PR is this?
/kind bug
What this PR does / why we need it:
EnsureAdminClusterRoleBindingImpl
assumed that the clientCreate()
call would returnnil
on error, but that's not how the real clients work; only the fake clients work that way. 😖Noticed while trying to fix that fact, #122892 (which this PR blocks). With fake client code that uses the real client semantics, the unit tests fail with:
FWIW the unit test probably would have caught this bug in one of the other sub-tests if it checked the error text rather than just checking "any error" vs "no error"... (Though I recognize that people have differing opinions on whether unit tests should check for specific error text...)
Which issue(s) this PR fixes:
none
Does this PR introduce a user-facing change?
probably? Also, the code is new in 1.29 but I don't know if that makes it
/kind regression
or if it's a bug in a new feature/assign @neolit123