openshift-kube-apiserver: use in-process loopback client config from Kube #20074
Conversation
openshift-ci-robot
added
the
size/M
|
I don't have the knowledge to sign off on this ;) |
|
LGTM Will defer to @deads2k to tag. |
|
/cherrypick release-3.10 |
|
@mfojtik: once the present PR merges, I will cherry-pick it on top of release-3.10 in a new PR and assign it to you. 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. |
|
/cc deads2k |
|
It's not pretty, but the flow is very confusing already, so I suppose it's ok. /lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, sttts 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 |
openshift-ci-robot
added
the
approved
|
/test all |
|
/retest |
|
@mfojtik: new pull request created: #20207 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. |
The loopback config from the master config might reference the master service. It is meant to be used by components which run out-of-process. The openshift-kube-apiserver though talks to itself and should use Kube's "magic" loopback client config instead, which also uses its own self-generated CA and cert (without the need to add 127.0.0.1 to the main server cert and without the need to know the master IP in advance).
Fixes #20060