-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add mutating webhook re-invocation details #1049
Conversation
/assign |
cc @yliaog |
bcff6b6
to
fe5bfe7
Compare
addressed comments, renamed v1beta1 field, outlined plan for dropping the field and requiring idempotence in v1 |
a5db4bd
to
4a47764
Compare
4a47764
to
19fd9af
Compare
/assign @deads2k |
that do not are broken for some set of user input. | ||
|
||
Note that idempotence (whether a webhook can successfully operate on its own output) is distinct from | ||
the `sideEffects` indicator, which describes whether a webhook can safely be called in `dryRun` mode. |
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.
Webhooks with side effects should not double-actuate their side effects, so I think it's not quite as separate as described. Do we need to tell webhooks whether they are looking at the first or second invocation?
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.
Do we need to tell webhooks whether they are looking at the first or second invocation?
I would avoid that if at all possible. Admission can already be invoked multiple times per API request in case of conflicts encountered inside a GuaranteedUpdate loop.
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.
That's a good point. Maybe we should say, "It's already the responsibility of webhooks with side effects to avoid double-actuating those side effects if they are invoked multiple times for the same attempted change (which can already happen if a PATCH is retried due to an etcd conflict)."
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.
How can a webhook detect this condition, though?
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 still think it'd be good to add a blurb about this.
It continues to be the responsibility of webhooks with side effects to avoid
double-actuating those side effects. Note that it is already possible for all
webhooks to be invoked multiple times for the same change, if the entire
admission process is retried due to an etcd conflict.
b5f9ae1
to
05248ef
Compare
05248ef
to
97332ab
Compare
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lavalamp, liggitt 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 |
Adds details of the opt-in re-invocation mechanism
/cc @deads2k @lavalamp