-
Notifications
You must be signed in to change notification settings - Fork 133
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
Implement Receiver resource filtering with CEL #948
base: main
Are you sure you want to change the base?
Conversation
@stefanprodan @matheuscscp I reworked it to filter the resources using CEL. I'm not quite sure that this is really that valuable, I suspect label filtering is also more efficient? There's some optimisation of the CEL that could be done within |
4969c46
to
1fe996b
Compare
995704b
to
d87dbfd
Compare
CEL for Receiver notification filtering This introduces CEL for filtering CEL resources in a Receiver. Users can define a CEL expression that is applied as a filter for resources that are identified for notification. A CEL expression that returns false means that a resource will not be annotated. Signed-off-by: Kevin McDermott <[email protected]>
d87dbfd
to
b1c4e7e
Compare
45bd724
to
1e6929c
Compare
This moves the JSON body to request.body from request to allow for future expansion with the headers. Add documentation for the CEL functionality to the receivers doc. Signed-off-by: Kevin McDermott <[email protected]>
1e6929c
to
d658d4a
Compare
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.
Thanks again for all the work here, @bigkevmcd! I'm very excited for this feature 😄
This is just a preliminary review. I will try to review this again soon.
w.WriteHeader(http.StatusBadRequest) | ||
return | ||
} | ||
if err := s.validate(ctx, receiver, r); err != 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.
As mentioned in the first PR, this line reads the request payload depending on the type of the Receiver. If that happens, newCELEvaluator()
further below will not be able to read the payload again. My suggestion is that we read the payload entirely into memory at some point earlier than both function calls and pass the payload to both.
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.
Ahhh...yes, I forgot about that, I guess I'm not triggering it because of the specific receiver type I'm using.
I will add a test and see what we can do about fixing it 😄
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.
Also I suggest reading the payload only after the Receiver object has been successfully fetched/identified to reduce the surface for DDoSing the server.
Signed-off-by: Kevin McDermott <[email protected]>
Signed-off-by: Kevin McDermott <[email protected]>
Signed-off-by: Kevin McDermott <[email protected]>
39d85c0
to
5a22c4f
Compare
Signed-off-by: Kevin McDermott <[email protected]>
5a22c4f
to
bddfd56
Compare
This implementation allows filtering of wildcarded resources for receivers using CEL expressions.
Closes: #491
Spec: #491 (comment)