Fix: properly load and parse NO_PROXY environment variable#2523
Fix: properly load and parse NO_PROXY environment variable#2523Ndugu2 wants to merge 1 commit intokubernetes-client:masterfrom
Conversation
Signed-off-by: Kosea Kalema <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Ndugu2 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
|
|
Welcome @Ndugu2! |
|
PR needs rebase. DetailsInstructions 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. |
## Summary Works around [kubernetes-client/python#2520](kubernetes-client/python#2520): `kubernetes.client.Configuration.__init__` reads `NO_PROXY`/`no_proxy` from the environment and then immediately overwrites `self.no_proxy = None`, so proxy-bypass rules from the env are silently dropped and all traffic is forced through the configured proxy. Adds a shared `apply_no_proxy_env_workaround()` helper in `dagster_k8s.client` and calls it from the three user-space Configuration-loading sites: - `dagster_cloud` `K8sUserCodeLauncher` (the agent itself) - `dagster_k8s` `K8sRunLauncher` (inherited by `CloudK8sRunLauncher`) - `dagster_k8s` `_PipesK8sClient` Not patched: `dagster-cloud-backend` metadaemons and `eks_k8s_client.py` — these run on the control plane, not in user clusters, so the env-var behavior doesn't apply. ## How it stays safe across versions The helper is idempotent — on kubernetes client versions where the upstream bug is fixed (or where `no_proxy` was never mishandled), it just re-applies the same value the library would have set. `dagster_k8s` is OSS so we can't pin the user's kubernetes client version; that's handled by the canary test below rather than a version gate. ## Test plan - [x] `pytest dagster_k8s_tests/unit_tests/test_client.py -k "no_proxy or canary"` — 4 new tests pass - Functional: helper applies `NO_PROXY` env var to the default `Configuration` - Prefers uppercase `NO_PROXY` over lowercase `no_proxy` when both are set - No-op when neither env var is set - **Canary** (`test_kubernetes_client_no_proxy_bug_canary`): directly asserts `kubernetes.client.Configuration()` clobbers `no_proxy` to `None` even when `NO_PROXY` is set. When a future client bump ships the fix from [PR #2523](kubernetes-client/python#2523), this assertion will flip and the test will fail loudly — our cue to delete `apply_no_proxy_env_workaround` and its call sites. - [x] `ruff format` + `ruff check` clean on all 5 edited files ## Changelog [dagster-k8s] Added a workaround for an upstream issue in the Kubernetes python client kubernetes-client/python#2520) where setting the NO_PROXY or no_proxy environment variable did not affect the configuration of kubernetes API calls. --------- Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]> Internal-RevId: f1dc73b86ce59834473c3b11a256aea278a1741b
What type of PR is this?
/kind bug
What this PR does / why we need it:
This PR fixes the handling of the
NO_PROXYenvironment variable in theConfigurationclass. Previously:NO_PROXYandno_proxywere set, the lowercase version could take precedence incorrectlyNO_PROXY=""was treated the same as if the variable wasn't setself.no_proxydefaulted toNoneinstead of an empty listThese issues caused proxy bypass settings to be ignored, breaking functionality for users relying on
no_proxyconfigurations.Which issue(s) this PR fixes:
Fixes #2520
Special notes for your reviewer:
The fix implements proper precedence checking using
in os.environrather thanos.getenv()to correctly detect when a variable exists even if it's empty. The value is now parsed into a list of domains with whitespace stripped.Test cases added cover:
NO_PROXYno_proxyDoes this PR introduce a user-facing change?