-
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
Make DefaultThreadsPerController, QPS and Burst configurable via flags #3156
Conversation
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 Once the patch is verified, the new status will be reflected by the 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. |
/kind feature |
/assign @dlorenc |
/ok-to-test |
02822f6
to
7f92037
Compare
cmd/controller/main.go
Outdated
cfg.Burst = *burst | ||
|
||
ctx := injection.WithNamespaceScope(signals.NewContext(), *namespace) | ||
if !*enableLeaderElection { |
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.
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?
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.
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.
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.
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?
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.
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?
nit: i think you have a few extra "```" characters in the release notes section as well :) |
/retest |
/test pull-tekton-pipeline-integration-tests |
1 similar comment
/test pull-tekton-pipeline-integration-tests |
/hold |
@vdemeester yes, knative dependencies bump was required to pick up the change to make QPS and Burst configurable.
Cool, will create another PR for bumping knative changes. |
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 |
[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 |
/kind feature |
/remove-kind feature |
/kind feature |
cfg.Burst = 2 * *burst | ||
|
||
ctx := injection.WithNamespaceScope(signals.NewContext(), *namespace) | ||
if !*disableHighAvailability { |
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.
This seems to be backwards? If disable is false, we should enable, but we're getting the context with HA disabled.
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.
Oh right, I think the flag used to be enableLeaderElection
(or something). cc @nishpa214
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.
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.
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>
@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! |
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>
@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?
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 |
@xiujuan95 You want to set those parameters for 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" |
@nishpa214 Thanks! |
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:
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