Certified Operator Build Guide
  • Introduction
  • What is an Operator?
  • Pre-Requisites
  • Helm Operators
    • Building a Helm Operator
      • Using a Single Image Variable (Red Hat Marketplace)
      • Dockerfile Requirements
      • Update the Controller Manager
      • Building and Pushing Image
  • Ansible Operators
    • Building an Ansible Operator
      • Using a Single Image Variable (Red Hat Marketplace)
      • Dockerfile Requirements
      • Update the Controller Manager
      • Building and Pushing Image
  • Golang Operator Gotcha's
    • Writing to the Status Subresource
  • OpenShift Deployment
    • Operator Metadata
      • Update CRDs from v1beta1
      • Creating the Metadata Bundle
      • Adjusting the ClusterServiceVersion
      • Reviewing your Metadata Bundle
      • Metadata Bundle Image
        • Managing OpenShift Versions
    • Installing an OpenShift Environment
    • Deploying onto OpenShift
  • Troubleshooting and Resources
    • Creating an Ansible Role From a Helm Chart
    • Security Context Constraints
    • Connect Metadata Test Results
    • Red Hat Marketplace Requirements
  • Appendix
    • What if I've already published a Community Operator?
      • Consuming Applications from RHCC
      • Applying Security Context Constraints
      • Choosing a Unique Package Name
      • Assembling the Metadata Bundle
    • Community Operators
    • AWS OpenShift 4 Cluster Quick Start Guide
    • Using Third Party Network Operators with OpenShift
      • Appendix A - CNI Operator Manifests
      • Appendix B - Cluster Network Status
      • Appendix C - Operator Group Manifest
      • Appendix D - Subscription Manifest
    • Bundle Maintenance After Migration
    • Frequently Asked Questions (FAQ)
    • Multi-Arch Operator Certification
      • Glossary of Terms
      • Requirements and Limitations
      • Building a Multi-Arch Operator Image
      • Scanning and Publishing
      • Updating the Bundle Image
Powered by GitBook
On this page
  • Supported Architectures
  • Core Requirements
  • Current Limitations
  1. Appendix
  2. Multi-Arch Operator Certification

Requirements and Limitations

PreviousGlossary of TermsNextBuilding a Multi-Arch Operator Image

Last updated 3 years ago

Supported Architectures

The full list of supported hardware platforms and associated architecture names is in the following table:

Platform

Architecture

Intel/AMD

amd64

IBM Z

s390x

IBM Power

ppc64le

ARM*

arm64

*The ARM platform is currently in Tech Preview for OpenShift, as .

Core Requirements

There are a number of technical and non-technical requirements that must be met before being able to certify or publish a non-Intel/AMD operator. The list of requirements are as follows:

  • A Certified Intel/AMD architecture operator and any applicable operands (container workloads deployed/managed by the operator controller)

  • At least three (3) projects created and published in Red Hat Partner Connect:

    • An Operator / Bundle project

      • Project type: Operator Bundle

      • Distribution method: Red Hat

    • An Operator Controller image project

      • Project type: Container

      • Distribution method: External

    • One or more Operand images (as applicable)

      • Project type: Container

      • Distribution method: External

  • All container images related to the operator must be hosted in an external registry

  • Your operator and operands must both support the CPU architectures that you intend to run on. In other words, you can't build an operator for another platform (such as IBM Z) if your operand only runs on AMD64 / Intel x86. The product (operands) must also support the new platform.

  • Each architecture image must be contained within a manifest list, with one manifest list for the operator and one for each of the operands. For example, a minimal multi-arch image layout might look like below (image and platform names are hypothetical):

    • An operator manifest list named/tagged as operator-image:v1.0 would be a manifest referring to these images:

      • operator-image:v1.0-amd64

      • operator-image:v1.0-othercpu

    • A single operand manifest list named/tagged as example-app:v1.0, and would refer to two other images matching the same architecture:

      • example-app:v1.0-amd64

      • example-app:v1.0-othercpu

Below is an illustration to help explain the relationship between the operator components and the various registries (RHCC, external, and scan). Please keep in mind that there could be more than one operand project/image whereas the diagram below only shows a single operand:

Current Limitations

There are a few limitations as well, which dictate the requirements:

  • Using the RHCC (Red Hat Container Catalog) registry and in turn the Red Hat distribution method will not work due to lacking support for manifest lists

  • There is no automated certification pipeline or test infrastructure in place for non-Intel/AMD architectures at this time

  • Non-Intel/AMD operators cannot be certified or published on their own, and must be published along with an Intel/AMD operator

Manifest lists are not yet fully supported by Red Hat Partner Connect. You can specify a manifest image by digest for scanning and mark it published in the project (should the image pass and become certified), but currently only architecture specific images are supported by for platform identification. Automatic platform identification by parsing the manifest list contents is not supported, so you may still wish to scan each architecture image individually if you'd like the platform to be listed correctly on .

recently announced
catalog.redhat.com
catalog.redhat.com