Skip to content

Conversation

@tmshort
Copy link
Contributor

@tmshort tmshort commented Nov 5, 2025

fix(grpc): Use passthrough resolver when proxy is detected

Fix CatalogSource reporting TRANSIENT_FAILURE in Hypershift guest clusters by automatically using the "passthrough" resolver scheme when a proxy is detected.

Root Cause:
The migration from grpc.Dial() to grpc.NewClient() introduced a resolver scheme issue. When grpc.NewClient() is used with WithContextDialer (for proxy support), gRPC defaults to the "dns" resolver which tries to resolve addresses client-side. In Hypershift, the catalog operator runs in the management cluster and connects via SOCKS5 proxy to catalog pods in the guest cluster. Service addresses like "service.namespace.svc:50051" only exist in the guest cluster's DNS and cannot be resolved from the management cluster, causing connections to fail with TRANSIENT_FAILURE.

Solution:
Automatically detect when a proxy is being used (proxyURL != nil) and prepend "passthrough:///" to the target address. The passthrough resolver bypasses client-side DNS resolution and delegates it to the custom dialer (proxy), which resolves addresses in the guest cluster where they exist.

This solution:

  • Requires no environment variables or configuration
  • Automatically activates only when proxy is used
  • Follows gRPC best practices per documentation
  • Simpler than alternative env var approaches (e.g., PR #3699)

Fixes: OCPBUGS-64574
Related: OCPBUGS-64631, operator-framework/operator-lifecycle-manager#3698, operator-framework/operator-lifecycle-manager#3699

🤖 Generated with Claude Code via /jira:solve OCPBUGS-64574

@openshift-ci-robot openshift-ci-robot added jira/severity-critical Referenced Jira bug's severity is critical for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Nov 5, 2025
@openshift-ci-robot
Copy link

@tmshort: This pull request references Jira Issue OCPBUGS-64574, which is invalid:

  • expected the bug to target the "4.21.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:

fix(grpc): Use passthrough resolver when proxy is detected

Fix CatalogSource reporting TRANSIENT_FAILURE in Hypershift guest clusters by automatically using the "passthrough" resolver scheme when a proxy is detected.

Root Cause:
The migration from grpc.Dial() to grpc.NewClient() introduced a resolver scheme issue. When grpc.NewClient() is used with WithContextDialer (for proxy support), gRPC defaults to the "dns" resolver which tries to resolve addresses client-side. In Hypershift, the catalog operator runs in the management cluster and connects via SOCKS5 proxy to catalog pods in the guest cluster. Service addresses like "service.namespace.svc:50051" only exist in the guest cluster's DNS and cannot be resolved from the management cluster, causing connections to fail with TRANSIENT_FAILURE.

Solution:
Automatically detect when a proxy is being used (proxyURL != nil) and prepend "passthrough:///" to the target address. The passthrough resolver bypasses client-side DNS resolution and delegates it to the custom dialer (proxy), which resolves addresses in the guest cluster where they exist.

This solution:

  • Requires no environment variables or configuration
  • Automatically activates only when proxy is used
  • Follows gRPC best practices per documentation
  • Simpler than alternative env var approaches (e.g., PR #3699)

Fixes: OCPBUGS-64574
Related: OCPBUGS-64631, operator-framework/operator-lifecycle-manager#3698, operator-framework/operator-lifecycle-manager#3699

🤖 Generated with Claude Code via /jira:solve OCPBUGS-64574

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 openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 5, 2025
@openshift-ci openshift-ci bot requested review from joelanford and oceanc80 November 5, 2025 21:29
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Nov 5, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: tmshort

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 /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 Nov 5, 2025
Fix CatalogSource reporting TRANSIENT_FAILURE in Hypershift guest clusters
by automatically using the "passthrough" resolver scheme when a proxy is
detected.

Root Cause:
The migration from grpc.Dial() to grpc.NewClient() introduced a resolver
scheme issue. When grpc.NewClient() is used with WithContextDialer (for
proxy support), gRPC defaults to the "dns" resolver which tries to resolve
addresses client-side. In Hypershift, the catalog operator runs in the
management cluster and connects via SOCKS5 proxy to catalog pods in the
guest cluster. Service addresses like "service.namespace.svc:50051" only
exist in the guest cluster's DNS and cannot be resolved from the management
cluster, causing connections to fail with TRANSIENT_FAILURE.

Solution:
Automatically detect when a proxy is being used (proxyURL != nil) and
prepend "passthrough:///" to the target address. The passthrough resolver
bypasses client-side DNS resolution and delegates it to the custom dialer
(proxy), which resolves addresses in the guest cluster where they exist.

This solution:
- Requires no environment variables or configuration
- Automatically activates only when proxy is used
- Follows gRPC best practices per documentation
- Simpler than alternative env var approaches (e.g., PR #3699)

Fixes: OCPBUGS-64574
Related: OCPBUGS-64631, operator-framework/operator-lifecycle-manager#3698, operator-framework/operator-lifecycle-manager#3699

🤖 Generated with [Claude Code](https://claude.com/claude-code) via /jira:solve OCPBUGS-64574

Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Todd Short <todd.short@me.com>
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Nov 6, 2025

@tmshort: 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-gcp-ovn 0b36b69 link true /test e2e-gcp-ovn
ci/prow/e2e-gcp-olm 0b36b69 link true /test e2e-gcp-olm
ci/prow/verify 0b36b69 link true /test verify

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.

@kuiwang02
Copy link
Contributor

the new code works, thanks. I already update the ticket.

@tmshort
Copy link
Contributor Author

tmshort commented Nov 6, 2025

Closing this to do the work upstream.

@tmshort tmshort closed this Nov 6, 2025
@openshift-ci-robot
Copy link

@tmshort: This pull request references Jira Issue OCPBUGS-64574. The bug has been updated to no longer refer to the pull request using the external bug tracker.

In response to this:

fix(grpc): Use passthrough resolver when proxy is detected

Fix CatalogSource reporting TRANSIENT_FAILURE in Hypershift guest clusters by automatically using the "passthrough" resolver scheme when a proxy is detected.

Root Cause:
The migration from grpc.Dial() to grpc.NewClient() introduced a resolver scheme issue. When grpc.NewClient() is used with WithContextDialer (for proxy support), gRPC defaults to the "dns" resolver which tries to resolve addresses client-side. In Hypershift, the catalog operator runs in the management cluster and connects via SOCKS5 proxy to catalog pods in the guest cluster. Service addresses like "service.namespace.svc:50051" only exist in the guest cluster's DNS and cannot be resolved from the management cluster, causing connections to fail with TRANSIENT_FAILURE.

Solution:
Automatically detect when a proxy is being used (proxyURL != nil) and prepend "passthrough:///" to the target address. The passthrough resolver bypasses client-side DNS resolution and delegates it to the custom dialer (proxy), which resolves addresses in the guest cluster where they exist.

This solution:

  • Requires no environment variables or configuration
  • Automatically activates only when proxy is used
  • Follows gRPC best practices per documentation
  • Simpler than alternative env var approaches (e.g., PR #3699)

Fixes: OCPBUGS-64574
Related: OCPBUGS-64631, operator-framework/operator-lifecycle-manager#3698, operator-framework/operator-lifecycle-manager#3699

🤖 Generated with Claude Code via /jira:solve OCPBUGS-64574

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.

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. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. jira/severity-critical Referenced Jira bug's severity is critical for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants