-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
Update CEL runtime cost limit #108595
Update CEL runtime cost limit #108595
Conversation
/cc @jpbetz |
/lgtm This is roughly what I was expecting for an initial limit given our current heuristic that 1 cost ~= 50ns. It seems high enough that it should be primarily a backstop for runaway execution. cc @liggitt @DangerOnTheRanger I expect we will refine this number before the release, but does this seem like a good starting point to you both? |
Yeah, I think especially that we should have an ample amount of time to change that limit if need be, it seems like a good place to start to me. |
// perCallLimit specify the actual cost limit per CEL validation call | ||
// current perCallLimit gives roughly one second for each expression validation call | ||
perCallLimit = 20000000 | ||
|
||
// RuntimeCELCostBudget is the overall cost budget for runtime CEL validation cost per CustomResource | ||
// current RuntimeCELCostBudget gives roughly 10 seconds for CR validation | ||
RuntimeCELCostBudget = 200000000 |
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.
since these represent dedicated CPU time, both of these are about an order of magnitude higher than I expected... are we really ok with 10 seconds of devoted CPU time per custom resource write validation?
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.
This number is fairly high now. I was thinking to start with a higher number and reduce based on performance run. Would you have any suggestions on the CPU time custom resource could consume?
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.
at most, I would expect fractions of a second of dedicated CPU per call and less than a second of dedicated CPU for validating the entire resource. I wouldn't start any higher than that, and would actually like to see that ramp even further down as we prove you can do significant amounts of complex validation with much lower limits. I'd probably drop an order of magnitude from each of these to start.
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 have updated to start with 2000000
for PerCallLimit
and 20000000
for RuntimeCELCostBudget
. cc @jpbetz @DangerOnTheRanger
@@ -92,34 +93,55 @@ func validator(s *schema.Structural, isResourceRoot bool) *Validator { | |||
} | |||
|
|||
// Validate validates all x-kubernetes-validations rules in Validator against obj and returns any errors. | |||
func (s *Validator) Validate(fldPath *field.Path, sts *schema.Structural, obj interface{}) field.ErrorList { |
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'm ignoring changes to this file and assuming this will be rebased on top of #108482
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.
Yes it is going to be rebased on #108482 . This PR is only for updating the budget. Thanks
/retest |
/test pull-kubernetes-e2e-kind-ipv6 |
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
these numbers look like plausible starting points... is there a tracking issue or spreadsheet item for finalizing these for 1.24? |
Here is the umbrella issue for tracking: #107573 |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cici37, 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 |
The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass. This bot retests PRs for certain kubernetes repos according to the following rules:
You can:
/retest |
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.
/retest
The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass. This bot retests PRs for certain kubernetes repos according to the following rules:
You can:
/retest |
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR is to update CEL runtime cost limit
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: