search

IBM / ibm-common-service-operator

Operator to install IBM Common Services
https://www.ibm.com/support/knowledgecenter/SSHKN6/kc_welcome_cs.html
Apache License 2.0
19 stars 71 forks source link

Upgrade of IBM Common Service operator and related dependencies #516

Open mhcastro opened 3 years ago

mhcastro commented 3 years ago

Hi folks! What would be the process to take on new updates of the IBM Common Services operator and other related dependencies with their respective container? For example, in the operator list below: what would be the approach to take new versions of the operator and/or the containers pulled automatically by the operator?

oc get csv -n ibm-common-services
NAME                                          DISPLAY                                VERSION   REPLACES                                      PHASE
ibm-common-service-operator.v3.6.5            IBM Cloud Platform Common Services     3.6.5     ibm-common-service-operator.v3.6.4            Succeeded
ibm-namespace-scope-operator.v1.0.2           IBM NamespaceScope Operator            1.0.2     ibm-namespace-scope-operator.v1.0.1           Succeeded
operand-deployment-lifecycle-manager.v1.4.3   Operand Deployment Lifecycle Manager   1.4.3     operand-deployment-lifecycle-manager.v1.4.2   Succeeded

The following indicates an automatic upgrade process every 45 minutes. But is there a manual task to take on new containers - e.g., let's say a new patched container image has been published to the registry?

spec:
  displayName: IBMCS Operators
  image: docker.io/ibmcom/ibm-common-service-catalog:latest
  publisher: IBM
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 45m

Thanks!

Daniel-Fan commented 3 years ago

Hi @mhcastro

On the current release of common service operator, we set the Operator's installPlanApproval to Automatic which means if there is a new available image in the CatalogSource, the olm-operator will upgrade the current operators to the latest version.

Therefore, if we want to pin the operator and its dependencies on the specific version, we have to tag the CatalogSource image at that version. For example,

spec:
  displayName: IBMCS Operators
  image: docker.io/ibmcom/ibm-common-service-catalog:3.6.5
  publisher: IBM
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 45m

Since their is no image update in that specific version of CatalogSource, the common service operator will remain at version 3.6.5.

In the next release, we will support to set the installPlanApproval to Manual in the common service operator's Subscription. In this case, even if we set the CatalogSource to latest and a new image has been published to the registry, we will still need to manually approve the upgrade process for common service operator and its dependencies.

I hope it would be helpful to you.

mhcastro commented 3 years ago

Thanks. Right, so if Cloud Registry image scanners identify any vulnerability on the latest, for example, OpenShift Quay Security Scanner, what would be the approach to highlight and patch these images?

Daniel-Fan commented 3 years ago

No, we would not patch the images that have been published. And I don't think we will highlight the current image which includes the vulnerability.

If there is any vulnerability issue found in the existing images on the latest CatalogSource, we will fix those issues in the next release. For example, if the latest image is version 3.6.5, then it will not be changed anymore. All the updates will go to the newer images like version 3.6.6.

mhcastro commented 3 years ago

Thanks @Daniel-Fan.