Bug 1760480

Summary:	[4.2.z] cluster-image-registry-operator container image is built with CGO_ENABLED=0
Product:	OpenShift Container Platform	Reporter:	Michał Dulko <mdulko>
Component:	Image Registry	Assignee:	Oleg Bulatov <obulatov>
Status:	CLOSED ERRATA	QA Contact:	Jon Uriarte <juriarte>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.2.0	CC:	aos-bugs, juriarte, obulatov, wzheng
Target Milestone:	---
Target Release:	4.2.z
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1760479	Environment:
Last Closed:	2019-11-13 18:55:51 UTC	Type:	---
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:	1760479
Bug Blocks:

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