-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Check for LimitRange Minimum for TaskRun Container Requests #1991
Check for LimitRange Minimum for TaskRun Container Requests #1991
Conversation
/test pull-tekton-pipeline-integration-tests |
6704bcd
to
f94a45b
Compare
pkg/pod/pod.go
Outdated
// Get LimitRange by name if present in ConfigMap tekton-limitrange-config. | ||
// Otherwise, pass empty request to resolveResourceRequests. | ||
limitRangeName := "" | ||
limitRangeConfig, err := kubeclient.CoreV1().ConfigMaps(taskRun.Namespace).Get("tekton-limitrange-config", metav1.GetOptions{}) |
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.
Would be open to changing tekton-limitrange-config
to something else in case this approach could be used to support other namespaced default values.
f94a45b
to
cc91153
Compare
cc91153
to
0905278
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.
Looks good! Would definitely like to see the configmap name and purpose documented as well.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbwsg 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 |
Thanks! I'll add the last changes you added and a doc. |
0905278
to
482085d
Compare
docs/tekton-limitrange-config.md
Outdated
minimum defined for container requests, a ConfigMap named `tekton-limitrange-config` can be | ||
created that holds the name of the LimitRange in the namespace where your TaskRuns are to be ran. | ||
|
||
An example `tekton-limitrange-config` is shown below: |
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.
nice 👍
@sbwsg Sorry to do this, but I changed this up a bit. While I was hesitant to do this because I am not sure how commonly used this will be, I think it makes more sense to add the If it is preferred to not add this field to the spec, I can go back to the config implementation. Otherwise, I can squash these commits and go with this new approach. |
@@ -66,6 +66,8 @@ type PipelineRunSpec struct { | |||
// with those declared in the pipeline. | |||
// +optional | |||
Workspaces []WorkspaceBinding `json:"workspaces,omitempty"` | |||
// +optional |
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.
could use a comment here describing the field's purpose. // LimitRangeName specifies the limit range to use for minimum resource values in task pods
or similar.
Same comment for taskrun_types in v1alpha1 and 2
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! Added along with some docs for pipelineruns/taskruns.
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.
👍 nice
9deecad
to
3991d39
Compare
docs/pipelineruns.md
Outdated
@@ -51,6 +51,10 @@ following fields: | |||
follow the instruction [here](taskruns.md#Configuring-default-timeout) to configure the | |||
default timeout, the same way as `TaskRun`. | |||
- [`podTemplate`](#pod-template) - Specifies a [pod template](./podtemplates.md) that will be used as the basis for the `Task` pod. | |||
- [`limitRangeName`](#limitrange-name) - Specifies the name of a LimitRange that exists in the namespace of the `PipelineRun`. This LimitRange's minimum | |||
for container resource requests will be used as part of requesting the appropriate amount of CPU, memory, and ephemeral storage for containers that are | |||
part of the `TaskRuns` of a `PipelineRun`. This proerty only needs to be specified if the `PipelineRun` is happening in a namespace with a LimitRange |
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.
nit: proerty
-> property
@@ -66,6 +66,8 @@ type PipelineRunSpec struct { | |||
// with those declared in the pipeline. | |||
// +optional | |||
Workspaces []WorkspaceBinding `json:"workspaces,omitempty"` | |||
// +optional |
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.
👍 nice
3991d39
to
8c0dab1
Compare
/lgtm |
Closes #1045
Closes #1920
Changes
This pull request adds the ability to specify a LimitRange name as part of how a TaskRun handles container resource requests. Currently, pipelines/tasks do not work when a LimitRange minimum is specified because all container requests that do not have the max values are set to 0. Since these requests are 0, they fail to meet the minimum specified and the TaskRun fails.
In order to specify a LimitRange name, a LimitRangeName property has been added to TaskRun/PipelineRun specs. The LimitRange name is then used to get the LimitRange, which is passed to
resolveResourceRequests
. LimitRanges were added to the 200-clusterrole.yaml to allow LimitRanges to be accessed.Open to suggestions on more robust testing and can also include docs/examples if helpful.
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes