Skip to content

OCPBUGS-74389: fix: create separate config client to resolve APIServer TLS update conflicts#3753

Merged
openshift-merge-bot[bot] merged 1 commit intooperator-framework:masterfrom
anik120:olm-operator-tls-config-fix
Jan 26, 2026
Merged

OCPBUGS-74389: fix: create separate config client to resolve APIServer TLS update conflicts#3753
openshift-merge-bot[bot] merged 1 commit intooperator-framework:masterfrom
anik120:olm-operator-tls-config-fix

Conversation

@anik120
Copy link
Copy Markdown
Member

@anik120 anik120 commented Jan 26, 2026

Description of the change:

Create a separate configclientset.Interface instance for the operator's proxy syncer. This ensures each SharedInformerFactory has its own client, preventing watch conflicts.

Motivation for the change:

The olm-operator fails to receive subsequent APIServer TLS configuration updates after the initial sync. This is because two SharedInformerFactory instances were being created from the same client, causing watch conflicts:

  1. APIServer TLS factory (created in SetupAPIServerTLSConfig)
  2. Proxy factory (created inside the OLM operator)

Both factories watch config.openshift.io resources but don't share watch state, leading to one factory not receiving all update events.

Architectural changes:

Testing remarks:

Reviewer Checklist

  • Implementation matches the proposed design, or proposal is updated to match implementation
  • Sufficient unit test coverage
  • Sufficient end-to-end test coverage
  • Bug fixes are accompanied by regression test(s)
  • e2e tests and flake fixes are accompanied evidence of flake testing, e.g. executing the test 100(0) times
  • tech debt/todo is accompanied by issue link(s) in comments in the surrounding code
  • Tests are comprehensible, e.g. Ginkgo DSL is being used appropriately
  • Docs updated or added to /doc
  • Commit messages sensible and descriptive
  • Tests marked as [FLAKE] are truly flaky and have an issue
  • Code is properly formatted

…nflicts

Problem:
The olm-operator fails to receive subsequent APIServer TLS configuration
updates after the initial sync. This is because two SharedInformerFactory
instances were being created from the same client, causing watch conflicts:

1. APIServer TLS factory (created in SetupAPIServerTLSConfig)
2. Proxy factory (created inside the OLM operator)

Both factories watch config.openshift.io resources but don't share watch
state, leading to one factory not receiving all update events.

Solution:
Create a separate configclientset.Interface instance for the operator's
proxy syncer. This ensures each SharedInformerFactory has its own client,
preventing watch conflicts.
@tmshort tmshort changed the title fix: create separate config client to resolve APIServer TLS update conflicts OCPBUGS-74389: fix: create separate config client to resolve APIServer TLS update conflicts Jan 26, 2026
@tmshort
Copy link
Copy Markdown
Contributor

tmshort commented Jan 26, 2026

/lgtm

@openshift-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Jan 26, 2026
@anik120
Copy link
Copy Markdown
Member Author

anik120 commented Jan 26, 2026

Created openshift/operator-framework-olm#1204 to test out fix in cluster. Test confirms fix works:

➜ oc get clusterversion 
NAME      VERSION                                                AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.22.0-0-2026-01-26-160049-test-ci-ln-v8sw84b-latest   True        False         10m     Cluster version is 4.22.0-0-2026-01-26-160049-test-ci-ln-v8sw84b-latest
➜  operator-framework-olm git:(tls-config-fix-test) oc patch apiserver cluster --type merge -p '{"spec":{"tlsSecurityProfile":{"type":"Modern","modern":{}}}}'
apiserver.config.openshift.io/cluster patched
➜  operator-framework-olm git:(tls-config-fix-test) oc logs -n openshift-operator-lifecycle-manager deploy/catalog-operator | grep -i "APIServer TLS"
time="2026-01-26T16:20:50Z" level=info msg="OpenShift APIServer API available - setting up watch for APIServer TLS configuration"
time="2026-01-26T16:20:50Z" level=info msg="APIServer TLS configuration will be applied to HTTPS servers"
time="2026-01-26T16:20:51Z" level=info msg="APIServer TLS configuration changed: profile=Intermediate (default), minVersion=TLS 1.2, cipherCount=9"
time="2026-01-26T16:55:40Z" level=info msg="APIServer TLS configuration changed: profile=Modern, minVersion=TLS 1.3, cipherCount=3"
➜  operator-framework-olm git:(tls-config-fix-test) oc logs -n openshift-operator-lifecycle-manager deploy/olm-operator | grep -i "APIServer TLS"
time="2026-01-26T16:20:50Z" level=info msg="OpenShift APIServer API available - setting up watch for APIServer TLS configuration"
time="2026-01-26T16:20:50Z" level=info msg="APIServer TLS configuration will be applied to HTTPS servers"
time="2026-01-26T16:20:50Z" level=info msg="APIServer TLS configuration changed: profile=Intermediate (default), minVersion=TLS 1.2, cipherCount=9"
time="2026-01-26T16:55:40Z" level=info msg="APIServer TLS configuration changed: profile=Modern, minVersion=TLS 1.3, cipherCount=3"

@tmshort
Copy link
Copy Markdown
Contributor

tmshort commented Jan 26, 2026

/approve

Since @camilamacedo86 approved it, along with me

@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented Jan 26, 2026

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: camilamacedo86, tmshort

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details 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

@openshift-ci openshift-ci Bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 26, 2026
@openshift-merge-bot openshift-merge-bot Bot merged commit 3e24482 into operator-framework:master Jan 26, 2026
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants