Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1760479

Summary:	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
Target Milestone:	---
Target Release:	4.3.0
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1760480 (view as bug list)		Environment:
Last Closed:	2020-01-23 11:07:15 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:	1760480

Description Michał Dulko 2019-10-10 15:55:09 UTC

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 4 Jon Uriarte 2019-10-25 10:21:47 UTC

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

Comment 6 errata-xmlrpc 2020-01-23 11:07:15 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-2020:0062