Description of problem: There's `CGO_ENABLED=0` added to `go build` when building the cluster-image-registry-operator. While this shouldn't be too much of an issue, it makes CIRO use Golang's internal DNS resolver (it's used e.g. to resolve auth_url of underlying OpenStack cloud). This implementation does not support `use-vc` option on resolv.conf. While this still shouldn't be a problem it actually is for deployments with Kuryr enabled. Kuryr creates an OpenStack Octavia load balancer for OpenShift services, including the DNS service. In supported version Octavia does not implement UDP load balancing. This means that Kuryr deployments rely on DNS resolution through TCP and in those each pod is injected with that option added to dnsConfig. With `CGO_ENABLED=0` that workaround doesn't work with CIRO. Version-Release number of selected component (if applicable): 4.2 How reproducible: Always Steps to Reproduce: 1. Deploy 4.2 with OpenStack and Kuryr on a cloud that has a domain in auth_url. Actual results: We can see in the logs CIRO is unable to connect to that auth_url and goes Degraded. Expected results: CIRO is able to resolve and connect to auth_url. Additional info:
Verified on upstream CI system, master (4.3) branch, which includes the fix for this BZ, and is also delivered in 4.3.0-0.nightly-2019-10-22-165241 build. It was not feasible to verify it in downstream CI system as we cannot point to an auth_url domain name. Upstream build: Config resolver info not provided; using env var or file instead Resolved source https://github.com/openshift/release to master@293a97f9, merging: #4292 3555dc0b @dulek Resolved source https://github.com/openshift/installer to master@ Resolved openshift/release:golang-1.12 to sha256:e9472f4f7ee87d693bd9bdcce70fd444c35d5fefee3b70f44236506f9a026bdf Resolved ocp/4.3:base to sha256:79c59692c9e81d5697759e165b813800453d31e4d3273fadf319e013f99f9d5f Using namespace ci-op-6v7r3wpz Steps: 1. auth_url in clouds.yaml needs to point to a domain url. clouds: openstack-cloud: auth: auth_url: https://kaizen.massopen.cloud:13000/v3 <<-------- username: "zzz-ci" project_id: xxxxxxxxxxxxxx project_name: "zzz-ci" user_domain_name: "Default" password: yyyyy region_name: "moc-xxx" interface: "public" identity_api_version: 3 2. Run the installer and see if image-registry operator is up: image-registry 0.0.1-2019-10-25-082130 True False False 60s 3. Check the swift object storage container is created bash-4.2$ openstack container list +----------------------------------------------------------------+ | Name | +----------------------------------------------------------------+ | 6v7r3wpz-6be7a-5btwt-image-registry-bqydpqdfthtivbakpvywsgpeur | | ... | +----------------------------------------------------------------+ This confirms that the domain name "kaizen.massopen.cloud" was resolved by image-registry operator For the record clouds.yaml is stored in base64 in the cluster: bash-4.2$ oc get secret -o yaml -n openshift-image-registry installer-cloud-credentials apiVersion: v1 data: clouds.yaml: XXxxxXXXInBaSe64== kind: Secret metadata: annotations: cloudcredential.openshift.io/credentials-request: openshift-cloud-credential-operator/openshift-image-registry-openstack creationTimestamp: "2019-10-25T08:37:15Z" name: installer-cloud-credentials namespace: openshift-image-registry resourceVersion: "1744" selfLink: /api/v1/namespaces/openshift-image-registry/secrets/installer-cloud-credentials uid: 6ff44d6f-2d34-44d3-93cf-fa9f511557fe type: Opaque
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, 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/RHBA-2020:0062