DRA CEL: add missing size estimator#129661
Conversation
|
Skipping CI for Draft Pull Request. |
|
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
23dcfed to
d979e57
Compare
|
/test pull-kubernetes-e2e-kind |
|
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. |
d979e57 to
e3d839f
Compare
|
@Adarsh-verma-14: the unit test failure is genuine, I'll have to update validation. |
| field(driverVar, apiservercel.StringType, true), | ||
| field(attributesVar, apiservercel.NewMapType(apiservercel.StringType, apiservercel.NewMapType(apiservercel.StringType, apiservercel.AnyType, resourceapi.ResourceSliceMaxAttributesAndCapacitiesPerDevice), resourceapi.ResourceSliceMaxAttributesAndCapacitiesPerDevice), true), | ||
| field(capacityVar, apiservercel.NewMapType(apiservercel.StringType, apiservercel.NewMapType(apiservercel.StringType, apiservercel.QuantityDeclType, resourceapi.ResourceSliceMaxAttributesAndCapacitiesPerDevice), resourceapi.ResourceSliceMaxAttributesAndCapacitiesPerDevice), true), | ||
| field(driverVar, driverType, true), |
There was a problem hiding this comment.
Just brainstorming on how to ensure someone doesn't accidentally forget to set a MaxElements on a type..
Option: field() takes the MaxElements as an argument, you could define consts for the values provided.
Option: field() takes a type alias to apiservercel.AnyType and this package provides a newType function that requires the MaxElements argument and returns the alias type.
Option: field() asserts that passed types (at least the string and bytes typed ones, maybe others) have MaxElements set.
There was a problem hiding this comment.
This isn't limited to fields, nor to this particular source code.
Someone else in some entirely different package might do apiservercel.NewMapType(apiservercel.StringType, apiservercel.StringType, myMaxNumberOfKeys) without realizing that they should use some custom string type with MaxElements set.
To disarm this footgun everywhere, those pre-defined types would have to be removed in favor of constructor methods which force passing a maxElements parameters.
Alternatively, the size estimator could refuse to use an unset MaxElements. But that then only fails if someone is careful with unit testing.
There was a problem hiding this comment.
True.. I'd be OK with opening a separate issue for the pre-defined types -> constructor method idea.
WDYT @cici37 is this something the CEL contributors would be willing to work on?
Not implementing a size estimator had the effect that strings retrieved from
the attributes were treated as "unknown size", leading to wildly overestimating
the cost and validation errors even for even simple expressions like this:
device.attributes["qat.intel.com"].services.matches("[^a]?sym")
Maximum number of elements in maps and the maximum length of the driver name
string were also ignored resp. missing. Pre-defined types like
apiservercel.StringType must be avoided because they are defined as having
a zero maximum size.
e3d839f to
2cc3dbf
Compare
|
/lgtm |
|
LGTM label has been added. DetailsGit tree hash: fe5a09234b007e7ae58eb414661716901e0c72ab |
|
/retest "Pod scheduling timeout". |
|
/label api-review |
|
|
||
| // DriverNameMaxLength is the maximum valid length of a driver name in the | ||
| // ResourceSliceSpec and other places. It's the same as for CSI driver names. | ||
| const DriverNameMaxLength = 63 |
There was a problem hiding this comment.
For reference:
kubernetes/pkg/apis/core/validation/validation.go
Lines 1688 to 1690 in 50fc400
There was a problem hiding this comment.
And
| if len(path) == 0 { | ||
| // Path() can return an empty list, early exit if it does since we can't | ||
| // provide size estimates when that happens | ||
| return nil |
There was a problem hiding this comment.
does a nil return turn into the worst-case size estimate?
There was a problem hiding this comment.
Yes, I believe so. This is copy-and-pasted from the size estimator
There was a problem hiding this comment.
The main difference compared to that one is injecting stronger typing of the attribute values:
https://github.com/pohly/kubernetes/blob/2cc3dbf2250177c60b2967e3e8481ac3f7e33829/staging/src/k8s.io/dynamic-resource-allocation/cel/compile.go#L398-L404
What's the rationale for backporting? At first glance, this looks like a pretty complex change to backport, and this isn't fixing a regression, right? |
|
/approve for API constants |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: liggitt, pohly The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Not a regression, but a pretty significant bug that limits what users can do with DRA in 1.32. I'll elaborate further on this in the cherry-pick PR and we can discuss there. |
…1-origin-release-1.32 Automated cherry pick of #129661: DRA CEL: add missing size estimator
What type of PR is this?
/kind bug
/priority important-soon
/assign @jpbetz
Needs to be backported to 1.32.
What this PR does / why we need it:
Not implementing a size estimator had the effect that strings retrieved from the attributes were treated as "unknown size", leading to wildly overestimating the cost and validation errors even for even simple expressions like this:
Maximum number of elements in maps and the maximum length of the driver name string were also ignored resp. missing. Pre-defined types like apiservercel.StringType must be avoided because they are defined as having a zero maximum size.
Which issue(s) this PR fixes:
Fixes #129523
Special notes for your reviewer:
This might change the cost estimate for some potentially stored CEL expressions involving the driver name. This is okay because the validation was implemented so that all stored expressions are assumed to be valid, i.e. a down- or upgrade will not lead to validation errors when the different versions of the apiserver implement cost estimation differently.
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: