Bug 1691547

Summary: CSV appears stuck (doesn't gain a status) when referenced CRDs have longer than anticipated API names or resource names
Product: OpenShift Container Platform Reporter: Paul Morie <pmorie>
Component: OLMAssignee: Evan Cordell <ecordell>
Status: CLOSED ERRATA QA Contact: Jian Zhang <jiazha>
Severity: urgent Docs Contact:
Priority: high    
Version: 4.1.0CC: afield, bandrade, chuo, scolange
Target Milestone: ---   
Target Release: 4.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-04 10:46:21 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:

Description Paul Morie 2019-03-21 21:12:23 UTC 
Description of problem:

https://github.com/operator-framework/operator-lifecycle-manager/pull/763 added code that labels a CSV with the names and API groups of CRDs referenced by the CSV. However, there is a 63 character limit on label names in kubernetes. As a consequence of this, if the constructed label name is longer than 63 characters, a created CSV will appear to be "stuck", ie, it does not take on any status information.

Relevant portion of logs from the install of federation (this was with my development version, but the problem should be reproducible using 0.0.6 version in community-operators):

E0321 20:43:36.486128       1 queueinformer_operator.go:177] Sync "federation-test/federation.v0.0.7" failed: ClusterServiceVersion.operators.coreos.com "federation.v0.0.7" is invalid: [metadata.labels: Invalid value: "olm.api.IngressDNSRecord.v1alpha1.multiclusterdns.federation.k8s.io": name part must be no more than 63 characters, metadata.labels: Invalid value: "olm.api.ServiceDNSRecord.v1alpha1.multiclusterdns.federation.k8s.io": name part must be no more than 63 characters, metadata.labels: Invalid value: "olm.api.ReplicaSchedulingPreference.v1alpha1.scheduling.federation.k8s.io": name part must be no more than 63 characters]
time="2019-03-21T20:43:36Z" level=error msg="Labels updated!" labels="olm.api.Cluster.v1alpha1.clusterregistry.k8s.io=provided,olm.api.DNSEndpoint.v1alpha1.multiclusterdns.federation.k8s.io=provided,olm.api.Domain.v1alpha1.multiclusterdns.federation.k8s.io=provided,olm.api.FederatedCluster.v1alpha1.core.federation.k8s.io=provided,olm.api.FederatedServiceStatus.v1alpha1.core.federation.k8s.io=provided,olm.api.FederatedTypeConfig.v1alpha1.core.federation.k8s.io=provided,olm.api.IngressDNSRecord.v1alpha1.multiclusterdns.federation.k8s.io=provided,olm.api.PropagatedVersion.v1alpha1.core.federation.k8s.io=provided,olm.api.ReplicaSchedulingPreference.v1alpha1.scheduling.federation.k8s.io=provided,olm.api.ServiceDNSRecord.v1alpha1.multiclusterdns.federation.k8s.io=provided"
time="2019-03-21T20:43:36Z" level=warning msg="issue ensuring csv api labels" csv=federation.v0.0.7 error="ClusterServiceVersion.operators.coreos.com \"federation.v0.0.7\" is invalid: [metadata.labels: Invalid value: \"olm.api.ServiceDNSRecord.v1alpha1.multiclusterdns.federation.k8s.io\": name part must be no more than 63 characters, metadata.labels: Invalid value: \"olm.api.ReplicaSchedulingPreference.v1alpha1.scheduling.federation.k8s.io\": name part must be no more than 63 characters, metadata.labels: Invalid value: \"olm.api.IngressDNSRecord.v1alpha1.multiclusterdns.federation.k8s.io\": name part must be no more than 63 characters]" id=iUv9W namespace=federation-test phase=


Version-Release number of selected component (if applicable):


How reproducible:

Install federation version 0.0.6 with community operators

Steps to Reproduce:
1. Watch the CSV; note that it gains no status
2. Scan olm-operator log for errors


Actual results:

CSV remains in a state without any status information indefinitely

Expected results:

- Resource names and API group names of arbitrary length should work correctly.
- If there is a problem that prevents servicing a CSV, there should be an indication in the CSVs status of what the problem is, so that a user can understand the problem without opening controller logs.
Comment 1 Jian Zhang 2019-03-22 06:14:18 UTC 
Paul,

Many thanks for your report! 

PS: the OLM version in the latest paylaod is: 5159b0a1c0dfe2cb76eb706afb4e3cc2ac4447fd, that above PR hasn't been merged in.
So, we cannot reproduce it, waiting for the newer OLM version.
Comment 2 Evan Cordell 2019-03-29 18:00:32 UTC 
Fixed in https://github.com/operator-framework/operator-lifecycle-manager/pull/778
Comment 4 Jian Zhang 2019-04-04 07:01:08 UTC 
The OLM version:  io.openshift.build.commit.id=9ba3512c5406b62179968e2432b284e9a30c321e

1, Install the federation operator on the Web console.
2, Check the olm-operator logs, didn't find the Errors.
3, The csv of the federation status shows "succeeded".
[jzhang@dhcp-140-18 444]$ oc get csv
NAME                        DISPLAY              VERSION   REPLACES                    PHASE
federation.v0.0.7           Federation           0.0.7                                 Succeeded

[jzhang@dhcp-140-18 444]$ oc get csv federation.v0.0.7 -o yaml
apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
...
  labels:
    olm.api.6c3df734d1d208fc: provided
    olm.api.29a256023848a274: provided
    olm.api.89e875d662667db9: provided
    olm.api.422c37778bd5e759: provided
    olm.api.707a6caafde1dce8: provided
    olm.api.88525a00ddf32edb: provided
    olm.api.c47d6dbf1bf2e2ad: provided
    olm.api.c599573f7cb189c: provided
    olm.api.eab48e18d2458ca0: provided
    olm.api.edd4aff9ba675121: provided
  name: federation.v0.0.7
  namespace: default

The labels have changed to the Hash, LGTM, verify it.
Comment 6 errata-xmlrpc 2019-06-04 10:46:21 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:0758