Description of problem: Having the catalog source hard-code its cluster.local suffix makes it impossible to deploy in environments which use different suffixes. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create a new or look at an existing CatalogSource Actual results: The status of the CatalogSource ends with `.cluster.local` Expected results: The status of the CatalogSource does not end with `.cluster.local` Additional info: Needed for the Submariner multi-cluster end-to-end tests, which use multiple suffixes.
Cluster version is 4.2.0-0.nightly-2019-09-10-181551 mac:~ jianzhang$ oc exec olm-operator-555db58556-dzd2h -- olm --version OLM version: 0.11.0 git commit: 5a5389cb8d831e79acade535d947d4ad4a5c40a7 1, I check an exist CatalogSource and don't find the status of the CatalogSource ends with `.cluster.local`, like below: mac:~ jianzhang$ oc get catalogsource certified-operators -o yaml apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: creationTimestamp: "2019-09-11T01:58:05Z" generation: 2 labels: olm-visibility: hidden openshift-marketplace: "true" opsrc-datastore: "true" opsrc-owner-name: certified-operators opsrc-owner-namespace: openshift-marketplace opsrc-provider: certified name: certified-operators namespace: openshift-marketplace resourceVersion: "37645" selfLink: /apis/operators.coreos.com/v1alpha1/namespaces/openshift-marketplace/catalogsources/certified-operators uid: 98037ee2-d437-11e9-9e00-0650cc4995e8 spec: address: 172.30.224.172:50051 displayName: Certified Operators icon: base64data: "" mediatype: "" publisher: Red Hat sourceType: grpc status: connectionState: address: 172.30.224.172:50051 lastConnect: "2019-09-11T03:18:25Z" lastObservedState: READY registryService: createdAt: "2019-09-11T01:58:05Z" protocol: grpc mac:~ jianzhang$ oc get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE certified-operators ClusterIP 172.30.224.172 <none> 50051/TCP 3h34m community-operators ClusterIP 172.30.98.245 <none> 50051/TCP 3h34m marketplace-operator-metrics ClusterIP 172.30.149.178 <none> 8383/TCP 4h51m redhat-operators ClusterIP 172.30.248.81 <none> 50051/TCP 3h34m mac:~ jianzhang$ oc project Using project "openshift-marketplace" on server "https://api.qitang.qe.devcluster.openshift.com:6443". 2, But, I'm confused about the code below. Like the code, if the `address` is empty, then will return the "status.registryService" address. https://github.com/skitt/operator-lifecycle-manager/blob/a011531d526d62384cecd67703b2554833527256/pkg/api/apis/operators/catalogsource_types.go#L112 But, I create/modify a CatalogSource without specific the 'addr'. But no address generated. Or ma I missing something? Change status to ASSIGNED first. mac:~ jianzhang$ oc get catalogsource -n default addr-operators -o yaml apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: creationTimestamp: "2019-09-11T06:38:17Z" generation: 1 name: addr-operators namespace: default resourceVersion: "126815" selfLink: /apis/operators.coreos.com/v1alpha1/namespaces/default/catalogsources/addr-operators uid: bcd67afa-d45e-11e9-9e46-0a0e54f0ee8e spec: address: "" displayName: Test Address Operators icon: base64data: "" mediatype: "" publisher: Red Hat sourceType: grpc
Hi Jian, Sorry that it was not clear from the bug report - the "address" is not generated by OLM when `address` is in the spec. Other CatalogSource configurations let OLM choose the address. For example: apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: operatorhubio-catalog namespace: olm spec: sourceType: grpc image: quay.io/operator-framework/upstream-community-operators:latest displayName: Community Operators publisher: OperatorHub.io This catalogsource does not have a spec.address field, and it will create a `service` resource and write the dns name to it in the status block. That is what changed - the auto-generated status address.
Hi, Evan Thanks for your explanation! I see. LGTM, verify it, details: Cluster version is 4.2.0-0.nightly-2019-09-11-032939 mac:~ jianzhang$ oc exec catalog-operator-68f64f5465-lz4rq -- olm --version OLM version: 0.11.0 git commit: 95572bce2416891c270c90a4437dc4a121a43e72 1, Create a CatalogSource, which consume image. Like below: mac:~ jianzhang$ oc create -f cs-42.yaml catalogsource.operators.coreos.com/test-operator created mac:~ jianzhang$ cat cs-42.yaml apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: test-operator namespace: default spec: sourceType: grpc image: quay.io/jiazha/etcd-operator:skip displayName: Test Operators publisher: Test 2, The address should be ServiceName.ServiceNamespace.svc:port mac:~ jianzhang$ oc get svc -n default NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 172.30.0.1 <none> 443/TCP 18h openshift ExternalName <none> kubernetes.default.svc.cluster.local <none> 18h test-operator ClusterIP 172.30.123.171 <none> 50051/TCP 2m23s mac:~ jianzhang$ oc get catalogsource -n default test-operator -o yaml apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: creationTimestamp: "2019-09-12T01:49:55Z" generation: 1 name: test-operator namespace: default resourceVersion: "293582" selfLink: /apis/operators.coreos.com/v1alpha1/namespaces/default/catalogsources/test-operator uid: 9ed9ba5d-d4ff-11e9-b9b0-fa163e50581b spec: displayName: Test Operators image: quay.io/jiazha/etcd-operator:skip publisher: Test sourceType: grpc status: connectionState: address: test-operator.default.svc:50051 lastConnect: "2019-09-12T01:50:21Z" lastObservedState: READY registryService: createdAt: "2019-09-12T01:49:55Z" port: "50051" protocol: grpc serviceName: test-operator serviceNamespace: default It's "test-operator.default.svc:50051", no ".cluster.local" suffix, LGTM.
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:2922