-
Notifications
You must be signed in to change notification settings - Fork 115
OCPBUGS-55335: apiserver: remove the requirement for LoopbackClientConfig #2276
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
base: master
Are you sure you want to change the base?
OCPBUGS-55335: apiserver: remove the requirement for LoopbackClientConfig #2276
Conversation
…or LoopbackClientConfig This setting is verifying that apiserver always have a config to connect to itself via loopback connection. This config includes a certificate key pair generated on the fly and stored in memory. This function is also used by library-go to create any controller (i.e. operator). The controllers don't need loopback connections to function, so it generates certificate keypairs and doesn't use them. Removing the requirement for LoopbackClientConfig won't affect how apiservers functions (all of them have it created and that doesn't change) and it allows library-go controllers to avoid creating in-memory certificate keypair not included in TLS registry
@vrutkovs: This pull request references Jira Issue OCPBUGS-55335, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. 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 openshift-eng/jira-lifecycle-plugin repository. |
@vrutkovs: the contents of this pull request could not be automatically validated. The following commits could not be validated and must be approved by a top-level approver:
Comment |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: vrutkovs 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 |
We don't have any operators that build against our Kubernetes fork, do we? If you wanted to pursue this approach I think you'd have to do it via https://github.com/openshift/kubernetes-apiserver/, but I don't think any of our operators should be using that, either. |
@vrutkovs: The following tests failed, say
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-sigs/prow repository. I understand the commands that are listed here. |
What type of PR is this?
/kind bug
What this PR does / why we need it:
This setting is verifying that apiserver always have a config to connect to itself via loopback connection. This config includes a certificate key pair generated on the fly and stored in memory.
This function is also used by library-go to create any controller (i.e. operator). The controllers don't need loopback connections to function, so it generates certificate keypairs and doesn't use them.
Removing the requirement for LoopbackClientConfig won't affect how apiservers functions (all of them have it created and that doesn't change) and it allows library-go controllers to avoid creating in-memory certificate keypair not included in TLS registry