Skip to content
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

Mutating webhooks should not continue if a handler throws..? #899

Open
btlghrants opened this issue Jun 17, 2024 · 0 comments
Open

Mutating webhooks should not continue if a handler throws..? #899

btlghrants opened this issue Jun 17, 2024 · 0 comments

Comments

@btlghrants
Copy link
Collaborator

Based on recent work in this issue, it appears that an unhandled failure within a mutating Action callback will be logged by Pepr but then will not prevent further processing of the associated admission request.

See the commented out test in this Excellent Example for a reproduction of the described behavior (where the failing Mutation() of a delete request still allows the resource to be deleted).

This might be a problem for a few of reasons:

  1. It is perfectly reasonable for a Module Author to want to run a series of mutating Action handlers against a resource in order to accomplish a desired goal and having one quietly fail while allowing others to act is likely to result in a resource with an intermediate state being submitted to the cluster.

  2. Relying on Pepr logs -- which end user's aren't really expected to have to check -- to identify issues regarding a resource request that explodes a failed mutating callback is misleading to the user (at best) -- as the user-facing request (via HTTP / kubectl) will appear to succeed -- even though not all the registered mutations will have occurred.

  3. Relying on Pepr logs to identify Action handler issues -- rather than rejecting admission requests outright -- loses out on the opportunity to provide direct feedback about errors occurring in the Pepr Action chain. This likely to greatly extend time-to-discovery of "bad handler" issues.

@btlghrants btlghrants added enhancement New feature or request and removed enhancement New feature or request labels Jun 17, 2024
@cmwylie19 cmwylie19 modified the milestone: v0.33.0 Jun 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📋 Backlog
Development

No branches or pull requests

2 participants