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...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Image Registry
Version: 4.2.0
Hardware: All
OS: All
medium
medium
Target Milestone: ---
: 4.2.z
Assignee: Oleg Bulatov
QA Contact: Jon Uriarte
URL:
Whiteboard:
Depends On: 1760479
Blocks:
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
Environment:
Last Closed: 2019-11-13 18:55:51 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift cluster-image-registry-operator pull 401 '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 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):
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:

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
name.

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

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

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.

https://access.redhat.com/errata/RHBA-2019:3303


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