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

Add validation rule for 'noRetry' parameter in ProvisioningRequestSpec #7547

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -113,6 +113,7 @@ type ProvisioningRequestSpec struct {
// +optional
// +kubebuilder:validation:XValidation:rule="self == oldSelf",message="Value is immutable"
// +kubebuilder:validation:MaxProperties=100
// +kubebuilder:validation:XValidation:rule="self.all(k, v, if parent.provisioningClassName == 'check-capacity.autoscaling.x-k8s.io' then k == 'noRetry' && v in ['true', 'false'] else true)",message="For check-capacity.autoscaling.x-k8s.io, only 'noRetry' parameter is supported with values 'true' or 'false'"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure we want to validate on the API level that only noRetry parameter is set.

My understanding is that the entire reason Parameters map exists is easy customisation for non-standard controllers, without requiring an API changes. If we're going to introduce it on the API level, we might just as well add a new field for it (although in this case I would suggest using maxRetries, since it's more flexible). It'd also be cleaner than code in comment, especially with a potentially growing set of parameters/classes to allow.

@mwielgus can you PTAL and decide if this is the way to go or not? Since this is effectively an API level change, it would require SIG chair approval anyway. My opinion is that we shouldn't go with it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather avoid adding explicit check for parameters. Parameters may be different for different classes and may come and go.

Parameters map[string]Parameter `json:"parameters"`
}

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -194,9 +194,6 @@ func (o *checkCapacityProvClass) checkCapacity(unschedulablePods []*apiv1.Pod, p
// condition block capacity in Kueue even if it's in the middle of backoff waiting time.
conditions.AddOrUpdateCondition(provReq, v1.Failed, metav1.ConditionTrue, conditions.CapacityIsNotFoundReason, "CA could not find requested capacity", metav1.Now())
} else {
if noRetry, ok := provReq.Spec.Parameters[NoRetryParameterKey]; ok && noRetry != "false" {
klog.Errorf("Ignoring Parameter %v with invalid value: %v in ProvisioningRequest: %v. Supported values are: \"true\", \"false\"", NoRetryParameterKey, noRetry, provReq.Name)
}
conditions.AddOrUpdateCondition(provReq, v1.Provisioned, metav1.ConditionFalse, conditions.CapacityIsNotFoundReason, "Capacity is not found, CA will try to find it later.", metav1.Now())
}
return err
Expand Down
Loading