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

Make DefaultThreadsPerController, QPS and Burst configurable via flags #3156

Merged
merged 1 commit into from
Oct 2, 2020

Conversation

pierretasci
Copy link

@pierretasci pierretasci commented Sep 1, 2020

Changes

Make DefaultThreadsPerController, QPS, and Burst configurable via flags. This helps tune a deployment depending on expected concurrency in production.

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

  • Includes tests (if functionality changed/added)
  • Includes docs (if user facing)
  • Commit messages follow commit message best practices
  • Release notes block has been filled in or deleted (only if no user facing changes)

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

Allows DefaultThreadsPerController, QPS, and Burst to be configured via flags

@tekton-robot tekton-robot added the do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. label Sep 1, 2020
@tekton-robot tekton-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Sep 1, 2020
@tekton-robot
Copy link
Collaborator

Hi @pierretasci. Thanks for your PR.

I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions 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/test-infra repository.

@tekton-robot tekton-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels Sep 1, 2020
@pierretasci
Copy link
Author

/kind feature

@tekton-robot tekton-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Sep 1, 2020
@pierretasci
Copy link
Author

/assign @dlorenc

@dibyom
Copy link
Member

dibyom commented Sep 1, 2020

/ok-to-test

@tekton-robot tekton-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Sep 1, 2020
@pierretasci pierretasci force-pushed the qps branch 2 times, most recently from 02822f6 to 7f92037 Compare September 2, 2020 18:13
cfg.Burst = *burst

ctx := injection.WithNamespaceScope(signals.NewContext(), *namespace)
if !*enableLeaderElection {
Copy link
Contributor

Choose a reason for hiding this comment

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

The leader election part worries me a bit. I think we'd want to setup some end to end testing of this before making it available.

Do you think it's worth trying to include in this change, or separating out to another PR where we can figure out the necessary testing plan?

Copy link

@nishpa214 nishpa214 Sep 2, 2020

Choose a reason for hiding this comment

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

To my understanding, I think if we remove the option of enabling leader election, it might be a breaking change, as the current release seems to support it via https://github.com/tektoncd/pipeline/blob/master/config/config-leader-election.yaml. I am not too super familiar with knative but looking through PR knative/pkg#1476, looks like one could enable it by setting EnabledComponents in the configmap.

I could break that out in a separate commit though, if we want to add some sort end to end test for it. I might need some guidance with that though, not sure what we might test in addition to what knative is already testing for :)

Either way, I guess we will want to add something in the release notes, if folks are using leader election now and how to use going forward.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, maybe my mistake then. It's not actually clear to me if that works. The comment is "an inactive but valid configuration follows": https://github.com/tektoncd/pipeline/blob/master/config/config-leader-election.yaml#L24

But either way - I'm not quite sure how not including this flag would be a breaking change. It didn't exist before, why do we need it here?

Choose a reason for hiding this comment

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

Yeah, me neither as we are not using this feature yet.

But either way - I'm not quite sure how not including this flag would be a breaking change. It didn't exist before, why do we need it here?

I meant from the feature perspective. If it's something user could enable before, and now no longer can if we disabled it.

@mattmoor can you shed some light on leader election config? Would there be any downside here if we remove the flag and enabled leader election by default?

@dlorenc
Copy link
Contributor

dlorenc commented Sep 2, 2020

nit: i think you have a few extra "```" characters in the release notes section as well :)

@nishpa214
Copy link

/retest

@imjasonh
Copy link
Member

imjasonh commented Sep 4, 2020

/test pull-tekton-pipeline-integration-tests

1 similar comment
@nishpa214
Copy link

/test pull-tekton-pipeline-integration-tests

@vdemeester
Copy link
Member

/hold
This bumps some k8s and knative dependencies. I guess the knative dependencies bump are required right ? (and the k8s ones might be a result of that update). We may want to split thoses (either in separate PR and/or commit), and we need to look at the knative changes (like the min support k8s version, …) before merging this.

@tekton-robot tekton-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 8, 2020
@nishpa214
Copy link

This bumps some k8s and knative dependencies. I guess the knative dependencies bump are required right ? (and the k8s ones might be a result of that update).

@vdemeester yes, knative dependencies bump was required to pick up the change to make QPS and Burst configurable.

We may want to split thoses (either in separate PR and/or commit), and we need to look at the knative changes (like the min support k8s version, …) before merging this.

Cool, will create another PR for bumping knative changes.

@tekton-robot tekton-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 15, 2020
@tekton-robot tekton-robot added size/S Denotes a PR that changes 10-29 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Sep 15, 2020
@tekton-robot tekton-robot removed the lgtm Indicates that a PR is ready to be merged. label Oct 2, 2020
@ghost
Copy link

ghost commented Oct 2, 2020

Since the most recent push is a commit message update I'm going to re-add @vdemeester 's lgtm and add my own approve:

/lgtm
/approve

@tekton-robot tekton-robot assigned ghost Oct 2, 2020
@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Oct 2, 2020
@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 Oct 2, 2020
@ghost ghost removed the kind/feature Categorizes issue or PR as related to a new feature. label Oct 2, 2020
@ghost
Copy link

ghost commented Oct 2, 2020

/kind feature

@tekton-robot tekton-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 2, 2020
@ghost
Copy link

ghost commented Oct 2, 2020

/remove-kind feature

@tekton-robot tekton-robot removed the kind/feature Categorizes issue or PR as related to a new feature. label Oct 2, 2020
@ghost
Copy link

ghost commented Oct 2, 2020

/kind feature

@tekton-robot tekton-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 2, 2020
@tekton-robot tekton-robot merged commit 995e44f into tektoncd:master Oct 2, 2020
@pierretasci pierretasci deleted the qps branch October 2, 2020 20:07
cfg.Burst = 2 * *burst

ctx := injection.WithNamespaceScope(signals.NewContext(), *namespace)
if !*disableHighAvailability {
Copy link
Member

Choose a reason for hiding this comment

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

This seems to be backwards? If disable is false, we should enable, but we're getting the context with HA disabled.

Copy link
Member

Choose a reason for hiding this comment

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

Oh right, I think the flag used to be enableLeaderElection (or something). cc @nishpa214

afrittoli added a commit to afrittoli/pipeline that referenced this pull request Oct 6, 2020
The tekton controller has a `disable-ha` flag that was introduced
in tektoncd#3156, which can be
used to disable support for leader-election-based HA.

The default for the disable flag is "false" i.e. support for HA
is meant to be enabled by default, however the current check on
the flag does the opposite of what it should, resulting in HA
being disabled by default.

This PR fixes the logic to restore the correct behaviour.
tekton-robot pushed a commit that referenced this pull request Oct 6, 2020
The tekton controller has a `disable-ha` flag that was introduced
in #3156, which can be
used to disable support for leader-election-based HA.

The default for the disable flag is "false" i.e. support for HA
is meant to be enabled by default, however the current check on
the flag does the opposite of what it should, resulting in HA
being disabled by default.

This PR fixes the logic to restore the correct behaviour.
vdemeester pushed a commit to vdemeester/tektoncd-pipeline that referenced this pull request Oct 12, 2020
The tekton controller has a `disable-ha` flag that was introduced
in tektoncd#3156, which can be
used to disable support for leader-election-based HA.

The default for the disable flag is "false" i.e. support for HA
is meant to be enabled by default, however the current check on
the flag does the opposite of what it should, resulting in HA
being disabled by default.

This PR fixes the logic to restore the correct behaviour.

(cherry picked from commit 2c76fc1)
Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
@xiujuan95
Copy link
Contributor

xiujuan95 commented Oct 12, 2020

@pierretasci I very like this PR. But could you pls tell me how can I configure the QPS, thread and burst? By a configMap, deployment or other kubernetes resources? And How can I check the change works? For example, the default QPS is 20, I want to modify it to 30. Then how can know I have changed it successfully? Is one kubernetes resource will show it? Thanks in advance!

tekton-robot pushed a commit that referenced this pull request Oct 12, 2020
The tekton controller has a `disable-ha` flag that was introduced
in #3156, which can be
used to disable support for leader-election-based HA.

The default for the disable flag is "false" i.e. support for HA
is meant to be enabled by default, however the current check on
the flag does the opposite of what it should, resulting in HA
being disabled by default.

This PR fixes the logic to restore the correct behaviour.

(cherry picked from commit 2c76fc1)
Signed-off-by: Vincent Demeester <vdemeest@redhat.com>
@xiujuan95
Copy link
Contributor

@pierretasci Sorry bother you again!

I want to change the default Thread/QPS/Burst to be 32/100/100, not sure if below setting is correct or not?

containers:
      - args:
        - -kube-api-qps=100
        - -kube-api-burst=100
        - -threads-per-controller=32

Because I don't know how to confirm this change takes effect, I need to get a sure answer about how to set the flag from you. Thanks in advance!

@pierretasci
Copy link
Author

@pierretasci Sorry bother you again!

I want to change the default Thread/QPS/Burst to be 32/100/100, not sure if below setting is correct or not?

containers:
      - args:
        - -kube-api-qps=100
        - -kube-api-burst=100
        - -threads-per-controller=32

Because I don't know how to confirm this change takes effect, I need to get a sure answer about how to set the flag from you. Thanks in advance!

@xiujuan95: @nishpa214 should be able to help with that

@nishpa214
Copy link

@xiujuan95 You want to set those parameters for tekton-pipelines-controller container in deployment spec. Here: https://github.com/tektoncd/pipeline/blob/master/config/controller.yaml#L76

You want to set them as following:

...
"-shell-image", "gcr.io/distroless/base:debug@sha256:72a0093a0214e414527a97d359313992534f94a689449615875d922097f0ba62",
"-kube-api-qps", "100",
"-kube-api-burst", "100",
"-threads-per-controller": "32"

@xiujuan95
Copy link
Contributor

xiujuan95 commented Oct 23, 2020

@nishpa214 Thanks!
But for the last one -threads-per-controller, I think it should be "-threads-per-controller", "32" rather than "-threads-per-controller": "32", right?

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. kind/feature Categorizes issue or PR as related to a new feature. lgtm Indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants