-
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 "Garbage collector should support cascading deletion of custom resources" flake #61499
Fix "Garbage collector should support cascading deletion of custom resources" flake #61499
Conversation
To support this claim, https://storage.googleapis.com/k8s-gubernator/triage/index.html?pr=1&text=internal%20error&test=should%20support%20cascading%20deletion%20of%20custom%20resources shows that the error only starts occuring around 16 days ago, right when my PR to add that webhook test was merged. |
/priority failing-test |
test/e2e/apimachinery/webhook.go
Outdated
Resources: []string{"*"}, | ||
APIGroups: []string{""}, | ||
APIVersions: []string{"v1"}, | ||
Resources: []string{"pods"}, |
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.
Maybe change it to some non-exist resources? Intercepting CRUD of "pods" can still break other tests.
d73643e
to
cd06e4d
Compare
/test pull-kubernetes-e2e-kops-aws |
/test pull-kubernetes-integration |
/test pull-kubernetes-e2e-kops-aws |
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: caesarxuchao, janetkuo, jennybuckley 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 |
Resources: []string{"*"}, | ||
APIGroups: []string{""}, | ||
APIVersions: []string{"v1"}, | ||
Resources: []string{"invalid"}, |
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 you want to make sure a failed hook can't prevent its own removal, you should match the webhook configuration resource and the delete operation, right?
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.
There is actually one configuration already doing that, these ones are there to test if a hook can prevent deleting another hook's configuration (to prevent a cycle of hooks preventing each other's deletions)
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.
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.
these ones are there to test if a hook can prevent deleting another hook's configuration
I don't see how selecting an invalid resource tests 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.
These webhook configurations should be able to be created and deleted without interference from the webhook I linked above. If webhooks are able to prevent deletion of other webhook configurations, the webhook I linked above will cause this check to fail, which it did, as shown in this test result from #59840 with just the test commit and not the fix:
test/e2e/apimachinery/webhook.go:147
deleting webhook config e2e-test-should-be-removable-validating-webhook-config with namespace e2e-tests-webhook-qlmqf
Expected error:
<*errors.StatusError | 0xc421454b40>: {
ErrStatus: {
TypeMeta: {Kind: "", APIVersion: ""},
ListMeta: {SelfLink: "", ResourceVersion: "", Continue: ""},
Status: "Failure",
Message: "admission webhook \"deny-webhook-configuration-deletions.k8s.io\" denied the request: this webhook denies all requests",
Reason: "",
Details: nil,
Code: 500,
},
}
admission webhook "deny-webhook-configuration-deletions.k8s.io" denied the request: this webhook denies all requests
not to have occurred
test/e2e/apimachinery/webhook.go:815
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 test goes like this:
- Create a webhook which is configured to prevent deletion of ValidatingWebhookConfiguration and MutatingWebhookConfiguration objects
- Attempt to create and delete a dummy ValidatingWebhookConfiguration
- Attempt to create and delete a dummy MutatingWebhookConfiguration
- Attempt to delete the webhook registered in (1) using this cleanup function which is called here
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 see, thanks.
Resources: []string{"*"}, | ||
APIGroups: []string{""}, | ||
APIVersions: []string{"v1"}, | ||
Resources: []string{"invalid"}, |
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.
Same here
Automatic merge from submit-queue (batch tested with PRs 61378, 60915, 61499, 61507, 61478). If you want to cherry-pick this change to another branch, please follow the instructions here. |
What this PR does / why we need it:
These webhook configuration objects were intended to have no effect on admission requests, and are just used to ensure that webhook configuration objects can always be deleted.
However, I think they are causing an entirely separate test to flake (Garbage collector should support cascading deletion of custom resources) because of the interaction between these two webhooks, which are run on all admission requests, and #61355 (Unable to create/update CRD when mutating webhook configured) when the two tests are run at around the same time.
This PR will make the effects of the webhook e2e test on other tests easier to reason about.
The flakiness is being caused by a legitimate failure of the underlying code (That CRDs currently don't work with webhooks), but not a failure which either of "Garbage collector should support cascading deletion of custom resources" or "AdmissionWebhooks Should not be able to prevent deleting validating-webhook-configurations or mutating-webhook-configurations" is supposed to reliably catch.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #59997
Release note:
/sig api-machinery
/kind flake