Goal:

Package Operator bundles in a way that runs well on clusters in a restricted network and/or production environment with OLM.

Why is this important:

• Better support users (ISV partners) in creating bundles for production environments.
  • Currently, pinning for RH products happens in OSBS. For partners, currently in IIB, because they are not built in the OSBS.
    • --> Partners want to be able to test their stuff fully before submitting it to RH.

• Complete our e2e story for Operator supports "disconnected" infrastructure.

For OCP clusters that are installed on restricted networks (AKA disconnected clusters), OLM can be configured to install and manage Operators from local sources on the mirror registry instead of the default remote sources.

For Operator authors, they would need to make sure their Operators meet requirements to run properly in a restricted network environment:

• In the cluster service version (CSV):
  • Under `.spec.relatedImages`, lists any related images, or other container images that your Operator might require to perform their functions.
  • Reference all specified images by a digest (SHA) and not by a tag.
     
• All dependencies of your Operator must also support running in a disconnected mode. Your Operator must not require any off-cluster resources.

SDK could help Operator authors to specify `.spec.relatedImages` in the CSV with related images by a digest (SHA) when generating bundles so all those images can be mirrored to the local registry and work with OLM in a disconnected OCP cluster.

Desired Outcome:

• SDK supports users to default generate digest-based bundle leveraging existing operator-manifest-tools (see in the below) for digest pinning.

Dependencies:

• Leverage an existing Operator Manifest Tools for digest pinning (also used by RH Pipeline)
  • https://github.com/operator-framework/operator-manifest-tools

• OLM epic - Simplify related images metadata: https://issues.redhat.com/browse/OLM-2177
  • Collaborate with the OLM team to see if the changes around `.spec.relatedImages` in the CSV impact this work.
    • See if SDK "still uses `.spec.relatedImages` in the CSV" or "just goes ahead and generates solely with `env vars` for related images".

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• Users generate digest-based bundles with the SDK for packing Operator bundles regardless of the Operator types (Go/Helm/Ansible)
• Upstream/downstream documents to guide users for the needed pre-reqs for Go/Helm/Ansible Operators. e.g.
  • how to instead of hardcode the img URL in controller Go code/Ansible tasks/Helm chart but lookup img ref in env vars for Operands' imgs
  • how to list image ref. in env vars so SDK tooling can grab them and build up CSV.spec.relatedImages for them

Related Information

• Ansible Blog post: https://cloud.redhat.com/blog/building-an-air-gap-friendly-operator

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>