Bug 1939435
| Summary: | Setting an IPv6 address in noProxy field causes error in openshift installer | |||
|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Constantin Vultur <cvultur> | |
| Component: | Networking | Assignee: | Andrey Lebedev <alebedev> | |
| Networking sub component: | router | QA Contact: | Hongan Li <hongli> | |
| Status: | CLOSED ERRATA | Docs Contact: | ||
| Severity: | low | |||
| Priority: | medium | CC: | amcdermo, anbhat, aos-bugs, bmcelvee, mmasters, ohochman, sasha, tsze, vemporop, yanyang | |
| Version: | 4.8 | |||
| Target Milestone: | --- | |||
| Target Release: | 4.10.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: |
Cause: The cluster-wide proxy configuration could not accept IPv6 addresses for noProxy setting.
Consequence: It was not possible to install a cluster whose configuration was having noProxy with IPv6 addresses.
Fix: Cluster Network Operator is now able to parse IPv6 addresses for the noProxy setting of the cluster-wide proxy resource.
Result: It's now possible to exclude IPv6 addresses from proxying.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 2004793 (view as bug list) | Environment: | ||
| Last Closed: | 2022-03-12 04:34:58 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 2004793, 2005095 | |||
|
Description
Constantin Vultur
2021-03-16 12:09:47 UTC
According to OCP docs the format of no_proxy is: "A comma-separated list of destination domain names, domains, IP addresses or other network CIDRs to exclude proxying." https://docs.openshift.com/container-platform/4.6/networking/enable-cluster-wide-proxy.html#enable-cluster-wide-proxy This seems an OpenShift bug. Either in the code (makes more sense), or in in the documentation. According to https://docs.openshift.com/container-platform/4.7/installing/installing_bare_metal/installing-bare-metal.html#installation-configure-proxy_installing-bare-metal, `install-config.yaml` may include a `noProxy` entry, which is "A comma-separated list of destination domain names, domains, IP addresses, or other network CIDRs to exclude proxying. Preface a domain with . to match subdomains only. For example, .y.com matches x.y.com, but not y.com. Use * to bypass proxy for all destinations." The documentation for both 4.7 and 4.6 states this. However, when I create an `install-config.yaml` that has an IPv6 address listed in `noProxy`, I get > ./openshift-install create ignition-configs > FATAL failed to fetch Kubeconfig Admin Client: failed to load asset "Install Config": invalid "install-config.yaml" file: proxy.noProxy[0]: Invalid value: "1001:db8::1": must be a CIDR or domain, without wildcard characters This does not happen with IPv6 CIDRs though, e.g. 1001:db8::0/120 passes fine. Invoking `openshift-install/openshift-baremetal-install` is exactly what Assisted Installer does in the case described in the bug. Using an IPv4 address doesn't cause errors either. The cluster-network-operator does not accept IPv6 addresses as valid NoProxy entries. The IPv4 addresses are accepted because they pass the regex to be considered domain names. If the correct behavior is to accept IPv6 addresses, then please open a bug against the installer once the changes are made to cluster-network-operator. The workaround at the moment is to specify any IPv6 address as /128. Dropping the severity given there is a workaround. Verified with 4.10.0-0.nightly-2021-09-15-220746 and passed. ### reproduced with old build without the fix and got error log: $ oc -n openshift-network-operator logs network-operator-f8478859-s6bjt | grep validate I0916 02:15:17.504205 1 log.go:184] Failed to validate proxy 'cluster': invalid noProxy: fd2e:6f44:5dd8::1 message: 'The configuration is invalid for proxy ''cluster'' (invalid noProxy: fd2e:6f44:5dd8::1). message: 'The configuration is invalid for proxy ''cluster'' (invalid noProxy: fd2e:6f44:5dd8::1). I0916 02:15:17.538812 1 log.go:184] Failed to validate proxy 'cluster': invalid noProxy: fd2e:6f44:5dd8::1 ### verified with 4.10.0-0.nightly-2021-09-15-220746 and got below results $ oc get proxies.config.openshift.io cluster -oyaml <---snip---> spec: httpProxy: http://user:xxxx@10.0.99.4:3128 httpsProxy: http://user:xxxx@10.0.99.4:3128 noProxy: test.no-proxy.com,registry.ocp-edge-cluster-0.qe.lab.redhat.com,ocp-edge-cluster-0.qe.lab.redhat.com,fd2e:6f44:5dd8::1,.ocp-edge-cluster-0.qe.lab.redhat.com trustedCA: name: "" status: httpProxy: http://user:xxxx@10.0.99.4:3128 httpsProxy: http://user:xxxx@10.0.99.4:3128 noProxy: .cluster.local,.ocp-edge-cluster-0.qe.lab.redhat.com,.svc,10.0.0.0/16,10.128.0.0/14,127.0.0.1,169.254.169.254,172.30.0.0/16,api-int.hongli-bv.qe.azure.devcluster.openshift.com,fd2e:6f44:5dd8::1,localhost,ocp-edge-cluster-0.qe.lab.redhat.com,registry.ocp-edge-cluster-0.qe.lab.redhat.com,test.no-proxy.com $ oc -n openshift-network-operator logs network-operator-7b6bf9c59c-5xkfg | grep validate (no output) $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.10.0-0.nightly-2021-09-15-220746 True False 54m Cluster version is 4.10.0-0.nightly-2021-09-15-220746 Hi, if there is anything that customers should know about this bug or if there are any important workarounds that should be outlined in the bug fixes section OpenShift Container Platform 4.10 release notes, please update the Doc Type and Doc Text fields. If not, can you please mark it as "no doc update"? Thanks! Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:0056 |