Fix operator installation in a disconnected environment

[tkrishtop]

This PR is to fix the DeployableByOlm test in disconnected environments.

Why DeployableByOlm fails in disconnected env

The test fails because of CSV failure, here are logs from preflight.log:

# subscription is reported to be ok
# csv is well-retrieved but never in the ready state
time="2022-01-10T08:48:50Z" level=debug msg="Waiting for object simple-demo-operator/simple-demo-operator.v0.0.3 to become ready..."
time="2022-01-10T08:48:53Z" level=debug msg="fetching csv simple-demo-operator.v0.0.3 from namespace simple-demo-operator"
time="2022-01-10T08:48:53Z" level=error msg="failed to fetch the csv simple-demo-operator.v0.0.3 from namespace simple-demo-operator: context deadline exceeded" 

From cluster logs we see that CSV is pending two images that failed to pull:

# CSV
NAME                                DISPLAY                      VERSION   REPLACES   PHASE
simple-demo-operator.v0.0.3         Simple Demo Operator         0.0.3                Installing

# images that are failing to pull
gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0 
quay.io/opdev/simple-demo-operator:0.0.3

These images could not be mirrored in the disconnected environment because the mirroring is done by digest (SHA) and images are referenced by tags.

What was done to fix

The tags were replaced by digests as in this PR, I rebuilt all images:

quay.io/tkrishtop/simple-demo-operator-catalog:0.0.3
quay.io/tkrishtop/simple-demo-operator-bundle:0.0.3
quay.io/tkrishtop/simple-demo-operator:0.0.3

and then tested the change by running Preflight tests with DCI. The tests are all green, here are results.json

{
  "image": "quay.io/tkrishtop/simple-demo-operator-bundle@sha256:e631c8dc7ab2d1ff67bf2731fd73820cb8e0214f9970d6ab1afca2f089d2fdb9",
  "passed": true,
  "certification_hash": "01139f58c09b2e5efcf99c9c8371dba9",
  "test_library": {
    "name": "github.com/redhat-openshift-ecosystem/openshift-preflight",
    "version": "1.0.6",
    "commit": "d01cac3c26138231eb9a19cd17b50f842e4f9c11"
  },
  "results": {
    "passed": [
      {
        "name": "ScorecardBasicSpecCheck",
        "elapsed_time": 14252,
        "description": "Check to make sure that all CRs have a spec block."
      },
      {
        "name": "ScorecardOlmSuiteCheck",
        "elapsed_time": 5213,
        "description": "Operator-sdk scorecard OLM Test Suite Check"
      },
      {
        "name": "DeployableByOLM",
        "elapsed_time": 89249,
        "description": "Checking if the operator could be deployed by OLM"
      },
      {
        "name": "ValidateOperatorBundle",
        "elapsed_time": 100,
        "description": "Validating Bundle image that checks if it can validate the content and format of the operator bundle"
      }
    ],
    "failed": [],
    "errors": []
  }
}

and CSV is ok in preflight.log

time="2022-01-14T11:41:07Z" level=debug msg="fetching csv simple-demo-operator.v0.0.3 from namespace simple-demo-operator"
time="2022-01-14T11:41:07Z" level=debug msg="CSV simple-demo-operator.v0.0.3 is created successfully in namespace simple-demo-operator"
time="2022-01-14T11:41:07Z" level=info msg="Successfully retrieved object simple-demo-operator/simple-demo-operator.v0.0.3"

[opdevbot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tkrishtop To complete the pull request process, please assign tonytcampbell after the PR has been reviewed. You can assign the PR to them by writing /assign @tonytcampbell in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files: - **[OWNERS](https://github.com/opdev/simple-demo-operator/blob/main/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[komish]

@tkrishtop This PR would work for the existing release, but the bundles are generated. We need to replace the tags with digests prior to bundle creation.

I can work this out, but I did have questions:

1) Is it just the images in the CSV that need tags? 2) Any concerns with our catalog image which we expect you to use via tag? 3) In the interest of moving forward (instead of retroactively changing 0.0.3), would it be acceptable for your use cases for me to push a 0.0.4 bundle that contains the images and leave the 0.0.3 as is?

Thanks!

[tkrishtop]

@komish thank you for the review!

Is it just the images in the CSV that need tags?

Yes, because this part is pulled during the execution, from the isolated cluster, and thus should be referred by digest (sha).

Any concerns with our catalog image which we expect you to use via tag?

Normally no. In disconnected environments, we regenerate common catalogs for all bundles to be used later on. And in the connected environments, the tag (and not digest) is fine. At least with the current fix in this PR, I got 4/4 test cases passing.

In the interest of moving forward (instead of retroactively changing 0.0.3), would it be acceptable for your use cases for me to push a 0.0.4 bundle that contains the images and leave the 0.0.3 as is?

Yes, perfectly fine, thank you.

Thanks!

[komish]

@tkrishtop I've just pushed out v0.0.4 that should include images referenced by digest. Please have a look, and if there's anything further, let me know. Otherwise, I'll let you close this out if all is addressed!

[opdevbot]

@tkrishtop: PR needs rebase.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.