This may not matter much once we get to the monorepo, but catalogd and operator-controller have different downstream “e2es”. The downstream catalogd e2e actually runs make test-e2e whereas operator controller doesn’t actually seem to do anything… This certainly explains why the catalogd e2e has been failing more often than the operator-controller.

catalogd e2e: https://github.com/openshift/release/blob/10b01da0eccb2840e16dbaaacbc82e9a4644d311/ci-operator/config/openshift/operator-framework-catalogd/openshift-operator-framework-catalogd-main.yaml#L82-L99

operator-controller e2e: https://github.com/openshift/release/blob/2da13cc507dd1dbb7fa4362736864d6c6b99a8c4/ci-operator/config/openshift/operator-framework-operator-controller/openshift-operator-framework-operator-controller-main.yaml#L76-L82

The catalogd e2e has the following difference:

    test:
    - as: upstream-e2e
      commands: make test-e2e
      dependencies:
      - env: TEST_CATALOG_IMAGE
        name: test-catalog
      from: src
      resources:
        requests:
          cpu: 100m
    - ref: openshift-e2e-test 

Since it’s just running make test-e2e, it’s not running any of the setup for the upstream catalogd e2e (i.e. running the image-registry target). So, it will fail.

Also note that catalogd make e2e runs the whole test (including creating a Kind cluster, setting up image registryies, etc.), whereas operator-controller make test-e2e is used to run the whole test (with Kind cluster). So there’s definitely some inconsistencies here.

Commit that introduced the e2es:

https://github.com/openshift/release/commit/7f78d57ec4425b5c83c981bb1c5fd92ad3065b56