fix: apply clientConnection QPS/burst to the manager client#3432
fix: apply clientConnection QPS/burst to the manager client#3432abhijeet-dhumal wants to merge 4 commits intokubeflow:masterfrom
Conversation
Signed-off-by: abhijeet-dhumal <abhijeetdhumal652@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Pull request overview
This PR fixes a wiring gap where clientConnection QPS/burst settings (already defaulted/validated in the Configuration API) were not being applied to the controller manager’s Kubernetes rest.Config, and adds Helm chart parity plus tests to prevent regression.
Changes:
- Adds
ApplyClientConnection()inpkg/configand applies it before creating the controller-runtime manager. - Extends the Helm chart to emit
clientConnectioninto the generated manager config. - Adds unit tests to cover applying
clientConnectionto arest.Config, including default and custom config loading.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
pkg/config/config.go |
Introduces ApplyClientConnection() to apply QPS/burst onto a rest.Config. |
pkg/config/config_test.go |
Adds tests for ApplyClientConnection() and for load+apply behavior. |
cmd/trainer-controller-manager/main.go |
Wires clientConnection into the manager’s REST config before ctrl.NewManager(). |
charts/kubeflow-trainer/values.yaml |
Adds manager.config.clientConnection values (qps/burst) with defaults. |
charts/kubeflow-trainer/templates/manager/configmap.yaml |
Renders clientConnection into the manager configmap template. |
| qps: {{ .Values.manager.config.clientConnection.qps | default 50 }} | ||
| burst: {{ .Values.manager.config.clientConnection.burst | default 100 }} |
There was a problem hiding this comment.
Using Helm's default here will treat explicit 0 as empty, so users cannot set clientConnection.qps/burst to 0 even though the API allows it; render the values directly (relying on values.yaml defaults) or gate on key existence (hasKey) instead of default so explicit 0 is preserved.
| qps: {{ .Values.manager.config.clientConnection.qps | default 50 }} | |
| burst: {{ .Values.manager.config.clientConnection.burst | default 100 }} | |
| qps: {{ dig "manager" "config" "clientConnection" "qps" 50 .Values }} | |
| burst: {{ dig "manager" "config" "clientConnection" "burst" 100 .Values }} |
Signed-off-by: abhijeet-dhumal <abhijeetdhumal652@gmail.com>
robert-bell
left a comment
There was a problem hiding this comment.
Thanks @abhijeet-dhumal this was a good spot.
|
|
||
| // ApplyClientConnection sets QPS and burst on the given rest.Config | ||
| // from the Configuration's clientConnection settings. | ||
| func ApplyClientConnection(restCfg *rest.Config, cfg *configapi.Configuration) { |
There was a problem hiding this comment.
what's the rationale for having a separate function for this rather than doing this as part of Load?
There was a problem hiding this comment.
Ah - re-reading this I see the rest config is created in main.go directly. A separate function makes sense.
| } | ||
|
|
||
| func TestApplyClientConnection(t *testing.T) { | ||
| testcases := []struct { |
There was a problem hiding this comment.
the convention is to use map-based test cases rather than list - could you udpate pls?
Line 130 in 7dfaa64
There was a problem hiding this comment.
Done ✅ - Converted both TestApplyClientConnection and TestLoadAndApplyClientConnection to use map-based test cases.
| } | ||
| } | ||
|
|
||
| func TestLoadAndApplyClientConnection(t *testing.T) { |
There was a problem hiding this comment.
Is this effectively re-testing logic we already cover in TestApplyClientConnection and TestLoad?
There was a problem hiding this comment.
Thanks for the review @robert-bell ! Addressed all your feedback ✅
There was a problem hiding this comment.
Thanks @abhijeet-dhumal. I was more wondering whether this test is needed?
…convention Signed-off-by: abhijeet-dhumal <abhijeetdhumal652@gmail.com>
Signed-off-by: abhijeet-dhumal <abhijeetdhumal652@gmail.com>
What this PR does / why we need it:
The clientConnection QPS/burst configuration is validated and defaulted but never applied to the manager's Kubernetes client.
Fixes #3431
Checklist: