-
Notifications
You must be signed in to change notification settings - Fork 594
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
helm: update helm API to be multi cluster aware #11030
Conversation
Adds a handler that picks the correct cluster according to requests, before handing the request to the corresponding helm handler. Closes: https://issues.redhat.com/browse/HELM-220 Signed-off-by: Allen Bai <carpe.diem.allen@gmail.com>
/test e2e-gcp-console |
@zonggen: all tests passed! Full PR test history. Your PR dashboard. 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. I understand the commands that are listed 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.
lgtm
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dperaza4dustbit, zonggen The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/assign @TheRealJon |
helmHandlers.ApiServerHost = s.K8sProxyConfigs[cluster].Endpoint.String() | ||
helmHandlers.Transport = s.K8sClients[cluster].Transport |
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.
Is this thread safe? What if two clients make requests for different clusters at the same time?
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.
No I don't think this is thread safe since we're changing the state of the server with each request. We probably need a solution that refactors the helm handler package to include mulitcluster config that sets up the handlers for each managed cluster at startup. Requests then can be directed to a pre-configured handler for the appropriate cluster without changing any state on the server.
We plan to change how multi-cluster works in 4.11 to use the ACM reverse proxy. We might hold off on the Helm changes until that's in place. Otherwise we'll need to rework this later. |
/hold |
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
@openshift-bot: Closed this PR. 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/test-infra repository. |
Adds a handler that picks the correct cluster according to requests,
before handing the request to the corresponding helm handler.
Closes: https://issues.redhat.com/browse/HELM-220
Signed-off-by: Allen Bai carpe.diem.allen@gmail.com