How to make operator installation method in OCP 4.2+ compatible with OCP 4.1

[horis233]

Type of question

Are you asking about community best practices, how to implement a specific feature, or about general context and help around the operator-sdk?

community best practices

Question

What did you do?

The steps for installation operators by CLI are quite different between OCP4.1 and OCP 4.2+.

When installing an operator from the OCP OperatorHub using the CLI,
in OCP 4.2+, users need to generate OperatorGroup and Subscription,
but for OCP 4.1, users need to generate CatalogSourceConfig and Subscription.

Moreover, it seems subscription in OCP 4.1 can't use the CatalogSource in the openshift-marketplace generated by OperatorSource and it has to use the CatalogSource in the target namespace generated by CatalogSourceConfig.

Thus, I want to ask how to install operators in OCP 4.1 by using the method from OCP4.2 (generating OperatorGroup and Subscription). Could you help to provide a best practice? (like upgrade olm?)

What did you expect to see?

I hope we can have a compatible way to install operators on OCP 4.1 and OCP 4.2+.

What did you see instead? Under which circumstances?

Currently, if using OCP 4.2+ methods to install operators on OCP 4.1. Subscription can't use the CatalogSource in the openshift-marketplace namespace and users have to generate CatalogSourceConfig to generate the CatalogSource in the target namespace of the operator.

Environment

• operator-lifecycle-manager version: 0.9.0

• Kubernetes version information: OCP 4.1

• Kubernetes cluster kind: OCP

/cc @gyliu513 @chenzhiwei @DanielXLee

[dmesser]

@horis233 In OCP 4.2 you can literally skip the CatalogSourceConfig as creating an OperatorSource will automatically create a CatalogSource.
Regarding your second question around namespaces: the default namespace in which OLM will look for global catalogs was incorrectly configured in OCP 4.1 (openshift-operator-lifecycle-manager instead of openshift-marketplace).
Overall the changes were too significant to backport, so unfortunately the differences will remain. However, as we are approaching OpenShift 4.4 the support for 4.1 will end and the process to install Operators is uniform across all currently supported OpenShift 4.x releases.

[dmesser]

I don't see this comment anymore on GitHub. Was the issue resolved?

…

On Thu, Apr 9, 2020 at 8:18 PM Denis Forveille ***@***.***> wrote: Just failed to configure aCatalogSourcefor operatorhub.io in OCP v4.3.1 . Help ! CatalogSource yaml: apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: operatorhubio-catalog namespace: openshift-marketplace spec: sourceType: grpc image: quay.io/operator-framework/upstream-community-operators:latest displayName: Community Operators publisher: OperatorHub.io oc describe pod operatorhubio-catalog-glftd: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled <unknown> default-scheduler Successfully assigned openshift-marketplace/operatorhubio-catalog-glftd to xxxx.xxxx.xxxx.xxxx.xxxx Normal Pulling 28m kubelet, xxxx.xxxx.xxxx.xxxx.xxxx Pulling image "quay.io/operator-framework/upstream-community-operators:latest" Normal Pulled 28m kubelet, xxxx.xxxx.xxxx.xxxx.xxxx Successfully pulled image "quay.io/operator-framework/upstream-community-operators:latest" Normal Created 28m kubelet, xxxx.xxxx.xxxx.xxxx.xxxxCreated container registry-server Normal Started 28m kubelet, xxxx.xxxx.xxxx.xxxx.xxxxxStarted container registry-server Warning Unhealthy 27m kubelet, xxxx.xxxx.xxxx.xxxx.xxxxReadiness probe failed: command timed out Warning Unhealthy 25m kubelet, xxxx.xxxx.xxxx.xxxx.xxxxLiveness probe failed: command timed out oc logs operatorhubio-catalog-glftd time="2020-04-09T17:39:46Z" level=info msg="serving registry" database=/bundles.db port=50051 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1320 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADAT2NO6IRR632KMQWV6RZTRLYGP5ANCNFSM4K23LP2Q> .

[chenzhiwei]

I think this issue will be automatically solved when OpenShift 4.1 reached end of life.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[horis233]

Since the OpenShift 4.1 isn't supported. Close this issue.