Skip to content

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

vrutkovs
Copy link
Member

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

…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
@openshift-ci-robot openshift-ci-robot added backports/unvalidated-commits Indicates that not all commits come to merged upstream PRs. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. labels Apr 25, 2025
@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Apr 25, 2025
@openshift-ci-robot openshift-ci-robot added the jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. label Apr 25, 2025
@openshift-ci-robot
Copy link

@vrutkovs: This pull request references Jira Issue OCPBUGS-55335, which is invalid:

  • expected the bug to target the "4.19.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

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

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.

@openshift-ci-robot
Copy link

@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 /validate-backports to re-evaluate validity of the upstream PRs, for example when they are merged upstream.

@openshift-ci openshift-ci bot requested review from benluddy and tkashem April 25, 2025 11:17
@openshift-ci openshift-ci bot added the vendor-update Touching vendor dir or related files label Apr 25, 2025
Copy link

openshift-ci bot commented Apr 25, 2025

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: vrutkovs
Once this PR has been reviewed and has the lgtm label, please assign tkashem for approval. For more information see the Code Review Process.

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@benluddy
Copy link

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.

Copy link

openshift-ci bot commented Apr 25, 2025

@vrutkovs: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/e2e-aws-ovn-runc 119ef25 link true /test e2e-aws-ovn-runc
ci/prow/e2e-aws-ovn-cgroupsv2 119ef25 link true /test e2e-aws-ovn-cgroupsv2
ci/prow/okd-scos-e2e-aws-ovn 119ef25 link false /test okd-scos-e2e-aws-ovn
ci/prow/e2e-agnostic-ovn-cmd 119ef25 link false /test e2e-agnostic-ovn-cmd
ci/prow/e2e-aws-ovn-serial 119ef25 link true /test e2e-aws-ovn-serial

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backports/unvalidated-commits Indicates that not all commits come to merged upstream PRs. jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. kind/bug Categorizes issue or PR as related to a bug. vendor-update Touching vendor dir or related files
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants