internal/olm/operator: fix operator-registry image for run packagemanifests

[joelanford]

Description of the change:

Fixed a bug with run packagemanifests that caused the underlying registry pod to fail to start. Changed the registry pod image from quay.io/openshift/origin-operator-registry:latest to quay.io/operator-framework/upstream-registry-builder:latest

Motivation for the change:
The run packagemanifests command is broken and needs to be fixed.

Checklist

If the pull request includes user-facing changes, extra documentation is required:

• Add a new changelog fragment in changelog/fragments (see changelog/fragments/00-template.yaml)
• Add or update relevant sections of the docs website in website/content/en/docs

[camilamacedo86]

I saw

 Waiting for Deployment \\\"default/e2e-fkkv-registry-server\\\" to rollout: 0 of 1 updated replicas are available\"\ntime=\"2020-09-04T15:34:20Z\" level=fatal msg=\"Failed to run packagemanifests: create catalog: error creating registry resources: error registering package: error waiting for Deployment \\\"default/e2e-fkkv-registry-server\\\" to roll out: timed out waiting for the condition\\n\"\n",

[camilamacedo86]

just a nit
otherwise, /lgtm

[camilamacedo86]

/lgtm
the nit is not a blocker at all.

[rashmigottipati]

/lgtm

[camilamacedo86]

@joelanford we have the test/integration using mock static data. It might be the case of the issue: https://travis-ci.org/github/operator-framework/operator-sdk/jobs/724251712#L1731

[openshift-ci-robot]

New changes are detected. LGTM label has been removed.

[Doout]

@joelanford Have this been tested on OCP (Openshift)? When I try out your fork, I am hitting a panic when it tries to run /bin/initializer -o bundle.db

Error: unable to open database file
Usage:
   [flags]

Flags:
  -h, --help               help for this command
  -m, --manifests string   relative path to directory of manifests (default "manifests")
  -o, --output string      relative path to a sqlite file to create or overwrite (default "bundles.db")
      --permissive         allow registry load errors

panic: unable to open database file

When I debug the pod (oc debug) and found that I get permission denied with touch which I assume the SQL package will also hit this (unable to open database file coming from SQL package)

/registry $ touch bundle.db
touch: bundle.db: Permission denied

When I run it as root, I face no issues. I assume the permission for /registry folder is not correct when it get deploy on OCP.
On OCP, UID is random while /registry ownership is root and no write access for any user

drwxr-xr-x    3 root     root            23 Sep  8 13:12 registry

[estroz]

@Doout this will need a follow-up to support all cluster types. Can you make an issue with the information in your comment above?