The alternative to registry deployment we came up with essentially removes a listening HTTP server and connect openshift-velero-plugin directly with the distribution/distribution code to serve requests from container/image/copy method as needed. A "library" to help achieve this is kaovilai/udistribution which may be moved to konveyor org.

OADP-Operator controller manager will

• set environment variables on the velero container
  • tell openshift-velero-plugin to initialize udistribution transport to be used to talk to storage drivers such as s3

openshift-velero-plugin will

• initialize udistribution transport to be used to talk to storage drivers such as s3
• use udistributionTransport.ParseReference

Alternatives considered

• Creating another Custom Resource from openshift-velero-plugin, watching for CR from oadp-operator controller-manager and acting upon the requests
  • openshift/oadp-operator#618: ImageStreamsBackup Custom Resource design.
  • Reasons against
    • Yet another custom resource/CRD. Increased debug complexity.
• Sidecar registry container inside velero pod
  • move registry container inside velero pod by kaovilai · Pull Request #700 · openshift/oadp-operator (github.com)
  • Reasons against
    • As BSLs are added, velero pod has to be recreated, thus causing running backups to fail or has to wait for backups to complete before a new BSL can have registry active.

Original issue
There are better solutions aside from our current workflow where we use the velero plugin system to backup images to a transient registry serially. We need to explore all alternatives and come up with a new design.

A few options:
1. Refactor existing plugin workflow to write directly to the s3 bucket
2. Implement a new API that allows a user to specify a set of images to backup to a backupstoragelocation
3. Anything....