-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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 QPS & burst options & flags for ClusterCacheTracker #10880
✨ Add QPS & burst options & flags for ClusterCacheTracker #10880
Conversation
/assign @fabriziopandini @chrischdi |
/test pull-cluster-api-e2e-main |
7745fd7
to
4115367
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.
/lgtm
/hold
LGTM label has been added. Git tree hash: 967378494ff97ec7a2a0aba9173dc7e9fc641309
|
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.
/lgtm
ok for me to cleanup flags as follow-up
4115367
to
24e89e8
Compare
Let's keep the hold until after the beta tag is created |
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.
/lgtm
LGTM label has been added. Git tree hash: 2349030491e1e1e769055962df11fa59c7cdc953
|
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.
One nit (no strong opinion)
Also, should we use new flags to increase QPS/Burst values in testenv?
Signed-off-by: Stefan Büringer buringerst@vmware.com
24e89e8
to
e86d00e
Compare
/lgtm |
LGTM label has been added. Git tree hash: 9b380c62de0715a90e66ea3482ddff9cd51e4739
|
/hold cancel |
(needs approve though @fabriziopandini @chrischdi ) |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: neolit123 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 |
/meow space |
In response to this:
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-sigs/prow repository. |
|
||
if opts.ClientQPS == 0 { | ||
opts.ClientQPS = 20 | ||
} | ||
if opts.ClientBurst == 0 { | ||
opts.ClientBurst = 30 | ||
} |
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.
I interpret that this case will be occurred when the someone specifies ClientQPS or ClientBurst to 0. If it fills out with default value arbitrarily, someone may think the 0 is valid value. So I think this case should return error.
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.
Nope, this cases get in two cases:
- when an implementer does not set
ClientQPS
and/orClientBurst
on the optsClusterCacheTrackerOptions
- when an implementer sets them, but the user passes in
0
as value
IMHO its fine as is.
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.
Hi @chrischdi
Thank you for teaching me 👍
when an implementer sets them, but the user passes in 0 as value
I just worried whether it's better that we let implementer know about the information when the actual value of ClientQPS and/or ClientBurst is different from args implementer sets. But I think it is fine too. Thanks.
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 problem here is that we don't know if someone set the fields explicitly to 0, or they are just 0 because 0 is the "zero value" of these fields.
I don't want to force everyone to set these values, which would happen if we always return an error if the fields are 0
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.
Hi @sbueringer
I understood it and I agree with your opinion. Surely, this field is option as it is named and it should not force everyone to set these.
Thanks.
/retest |
…urst ✨ Add QPS & burst options & flags for ClusterCacheTracker
Can we backport this @sbueringer ? |
Yup /cherry-pick release-1.7 |
@sbueringer: #10880 failed to apply on top of branch "release-1.7":
In response to this:
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-sigs/prow repository. |
If you open a cherry-pick PR 😀 |
Signed-off-by: Stefan Büringer buringerst@vmware.com
What this PR does / why we need it:
Before this PR we were using client-go defaults of 5 & 10 qps & burst. This PR changes the defaults to use the same as we use for the mgmt cluster client. It also makes these values configurable to allow fine-tuning at scale.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #