Bug 1760480 - [4.2.z] cluster-image-registry-operator container image is built with CGO_ENABLED=0
Summary: [4.2.z] cluster-image-registry-operator container image is built with CGO_ENA...
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Image Registry
Version: 4.2.0
Hardware: All
OS: All
Target Milestone: ---
: 4.2.z
Assignee: Oleg Bulatov
QA Contact: Jon Uriarte
Depends On: 1760479
TreeView+ depends on / blocked
Reported: 2019-10-10 15:57 UTC by Michał Dulko
Modified: 2019-11-13 18:56 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1760479
Last Closed: 2019-11-13 18:55:51 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift cluster-image-registry-operator pull 401 0 'None' 'closed' '[release-4.2] Bug 1760480: Remove CGO_ENABLED=0 from build script' 2019-11-19 15:43:37 UTC
Red Hat Product Errata RHBA-2019:3303 0 None None None 2019-11-13 18:56:02 UTC

Description Michał Dulko 2019-10-10 15:57:47 UTC
+++ This bug was initially created as a clone of Bug #1760479 +++

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):

How reproducible:

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:

Comment 2 Jon Uriarte 2019-10-28 17:12:24 UTC
Verified on upstream CI system, 4.2 branch, which includes the fix for this BZ, and is also delivered
in 4.2.0-0.nightly-2019-10-25-135517 build.

It was not feasible to verify it in downstream CI system as we cannot point to an auth_url domain

Upstream build:
 Config resolver info not provided; using env var or file instead
 Resolved source https://github.com/openshift/release to master@aceed011, merging: #4292 88930d9d @dulek
 Resolved source https://github.com/openshift/installer to release-4.2@
 Resolved openshift/release:golang-1.12 to sha256:cc529ba11251c061088af76f27dd1eaa82381bd9566f10a3c57eda11a276623a
 Resolved ocp/4.3:base to sha256:79c59692c9e81d5697759e165b813800453d31e4d3273fadf319e013f99f9d5f
 Using namespace ci-op-47xgcz71


1. auth_url in clouds.yaml needs to point to a domain url.

      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-28-154623   True        False         False      11m

3. Check the swift object storage container is created

bash-4.2$ openstack container list
| Name                                                           |
| 47xgcz71-1c3d7-w9qx4-image-registry-knpjoxghpuytxlopdxedrlgdfi |
| ...                                                            |

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
  clouds.yaml: XXxxxXXXInBaSe64==
kind: Secret
    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

Comment 4 errata-xmlrpc 2019-11-13 18:55:51 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.