Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-59756

High estimated costs for resource quantity in CEL expressions

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Normal Normal
    • 4.20.0
    • 4.18, 4.19, 4.20
    • kube-apiserver
    • None
    • Quality / Stability / Reliability
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • None
    • None
    • Done
    • Bug Fix
    • Hide
      * Before this update, the runtime cost estimator for `IntOrString` types did not account for the maximum length in the CRD schema which caused high runtime cost estimates for unbounded `IntOrStrings`. With this release, the CEL cost estimator now accounts for for the maximum length of the string and CEL validations, including the `IntOrString` types, can now be used within CRD schemas. (link:https://issues.redhat.com/browse/OCPBUGS-59756[*OCPBUGS-59756*])
      -------
      Cause: The runtime cost estimator for IntOrString types did not account for the maximum length in the CRD schema
      Consequence: Very high runtime costs were estimated for unbounded IntOrStrings
      Fix: The CEL cost estimator now accounts for the maximum length of the string, per the openapi schema
      Result: CEL validations including the IntOrString types can now be used within CRD schemas
      Show
      * Before this update, the runtime cost estimator for `IntOrString` types did not account for the maximum length in the CRD schema which caused high runtime cost estimates for unbounded `IntOrStrings`. With this release, the CEL cost estimator now accounts for for the maximum length of the string and CEL validations, including the `IntOrString` types, can now be used within CRD schemas. (link: https://issues.redhat.com/browse/OCPBUGS-59756 [* OCPBUGS-59756 *]) ------- Cause: The runtime cost estimator for IntOrString types did not account for the maximum length in the CRD schema Consequence: Very high runtime costs were estimated for unbounded IntOrStrings Fix: The CEL cost estimator now accounts for the maximum length of the string, per the openapi schema Result: CEL validations including the IntOrString types can now be used within CRD schemas
    • None
    • None
    • None
    • None

      Description of problem:

          Described in full on the upstream PR, https://github.com/kubernetes/kubernetes/pull/132837

There is an issue with resource.Quantity and other IntOrString style fields, where the CEL validation does not correctly account for the maximum length of the field per the open api validation.

Prior to the fix, the validation

// +kubebuilder:validation:XValidation:rule="isQuantity(self) && quantity(self).isGreaterThan(quantity('0'))",message="request must be a positive, non-zero quantity"

Would fail as it declared the validation cost was too high, even when limiting the length of the string.

With the upstream fix, the length of the string is now correctly taken into account and the runtime cost is correctly calculated.

      Version-Release number of selected component (if applicable):

      How reproducible:

          100%

      Steps to Reproduce:

          See https://github.com/kubernetes/kubernetes/pull/132837    

      Actual results:

      Expected results:

      Additional info:

              joelspeed Joel Speed
              joelspeed Joel Speed
              None
              None
              Ke Wang Ke Wang
              None
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: