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

Check for LimitRange Minimum for TaskRun Container Requests #1991

Merged
merged 1 commit into from
Feb 5, 2020

Conversation

danielhelfand
Copy link
Member

@danielhelfand danielhelfand commented Feb 1, 2020

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

Allow pipelines/tasks to work when LimitRange minimum is set by specifying a LimitRangeName as part of TaskRun/PipelineRun specs

@googlebot googlebot added the cla: yes Trying to make the CLA bot happy with ppl from different companies work on one commit label Feb 1, 2020
@tekton-robot tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Feb 1, 2020
@danielhelfand
Copy link
Member Author

/test pull-tekton-pipeline-integration-tests

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{})
Copy link
Member Author

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.

pkg/pod/resource_request.go Outdated Show resolved Hide resolved
pkg/pod/resource_request.go Outdated Show resolved Hide resolved
pkg/pod/pod.go Outdated Show resolved Hide resolved
Copy link

@ghost ghost left a 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.

pkg/pod/resource_request.go Outdated Show resolved Hide resolved
pkg/pod/resource_request.go Outdated Show resolved Hide resolved
@tekton-robot
Copy link
Collaborator

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 3, 2020
@danielhelfand
Copy link
Member Author

Looks good! Would definitely like to see the configmap name and purpose documented as well.

Thanks! I'll add the last changes you added and a doc.

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:
Copy link

Choose a reason for hiding this comment

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

nice 👍

@danielhelfand
Copy link
Member Author

@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 LimitRangeName to the pipelinerun/taskrun specs and avoid using a separate config.

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
Copy link

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

Copy link
Member Author

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.

Copy link

Choose a reason for hiding this comment

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

👍 nice

@@ -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
Copy link

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
Copy link

Choose a reason for hiding this comment

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

👍 nice

@ghost
Copy link

ghost commented Feb 5, 2020

/lgtm

@tekton-robot tekton-robot assigned ghost Feb 5, 2020
@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Feb 5, 2020
@tekton-robot tekton-robot merged commit 63e6cda into tektoncd:master Feb 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cla: yes Trying to make the CLA bot happy with ppl from different companies work on one commit lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Specify LimitRange Minimum as Part of Task Definition Leave Resource Request Empty Instead of Requesting 0
3 participants