-
Notifications
You must be signed in to change notification settings - Fork 386
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
Enabling Validating and Mutating Webhook's for KCP #818
Enabling Validating and Mutating Webhook's for KCP #818
Conversation
b0b3fc0
to
16b708f
Compare
e139ced
to
9fe6e2d
Compare
9fe6e2d
to
0a26674
Compare
// Determine the type of request, is it api binding or not. | ||
if workspace, isAPIBinding := p.getAPIBindingWorkspace(attr, lcluster); isAPIBinding { | ||
wh := p.restrictToLogicalCluster(hooks, workspace) | ||
whAccessor = append(whAccessor, wh...) |
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 want to replace the hooks with wh
, not just add them, at least that's true for status updates (= status subresource). cc @ncdc
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.
a cluster-admin couldn't have a webhook for a bound resource in their cluster then? at least that was the use case that I was thinking of
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 don't think this is a use case we'd want to enable, at least not without further discussion (i.e. let's get this PR ready + merged without this, and consider it for the future).
In the typical (non admin) use case, an API provider provides APIs, and that includes validating + mutating webhooks. API consumers must not be able to change validating/mutating behaviors, or at least I don't think they should be able to (?). Allowing cluster-admins to do so would make things much harder for the API provider to debug when things go wrong.
e280866
to
4d14315
Compare
9f138df
to
e0c9fca
Compare
66404b9
to
0414709
Compare
test/e2e/conformance/webhook_test.go
Outdated
}, wait.ForeverTestTimeout, 100*time.Millisecond) | ||
|
||
//Avoid race condition where webhook informer is not updated before the call to create was made. | ||
t.Log("Verify webhook is eventually called") |
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.
here we also have the race about the two eventually calls.
For this to land, also for @ncdc to pick this up in review later today:
|
2c034f2
to
4b9439f
Compare
…ng webhooks * adding a test case for validating webhook * add a generic kcp webhook dispatcher for validationg and mutating webhooks. * Adding e2e tests for new plugins * admission/webhooks: add index by workspace for bindings * Adding indexer to the generic webhook struct
4b9439f
to
dfee47b
Compare
dfee47b
to
bea27fc
Compare
Summary
Adding a conformance test to prove kcp-dev/kubernetes#52 is working as expected
Another follow on PR is going to need to test this using the APIBindings type to pass webhooks along.
Related issue(s)
Fixes #