Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PROOF OF CONCEPT: onboarding operators to FBC via a script and use of composite catalog template #4394

Conversation

grokspawn
Copy link

To reduce complex processing flows in the pipeline for operator authors wishing to onboard to FBC, we prefer advertised interfaces and valid FBC instead of relying on specific tooling and knowledge of FBC "precursors".

This high-level catalog publishing flow illustration breaks the FBC-to-catalog into three logical phases:

  1. build the update graph FBC (possibly as a result of a new bundle version published)
  2. validate and aggregate (non-FBC & FBC) contributions
  3. publish the aggregate in an accessible registry

Before those steps can execute, operator authors need to be able to onboard to FBC.

This POC demonstrates the use of a script to fulfill an FBC onboarding process for one/more authors with clear messaging and interfaces, and provide capabilities to fulfill (1) above, external to any catalog construction pipeline. It will:

  1. cache the (controlled by script vars) appropriate version of the catalog as FBC
  2. extract the operator's catalog contribution from the catalog and convert to a basic catalog template
  3. scaffold a composite template to generate FBC for all supported OCP versions
  4. template a Makefile in the operator's subdirectory which will be configured by default to use the composite template to generate contributions via catalog make target.
  5. mark the operator's ci.yaml file as FBC-onboarded by setting updateGraph property to "FBC".

Conventions:

  1. uses yq/yaml
  2. requires being executed from local repo root (and enforces it)
  3. presumes the directory structure
operators/$operator_name
├── catalog-data
│   └── basic-catalog-template.yaml
└── ci.yaml

Signed-off-by: Jordan Keister <jordan@nimblewidget.com>
@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Apr 22, 2024
@grokspawn
Copy link
Author

Moving proof of concept PR from k8s-operatorhub/community-operators since that may be deprecated.

@Allda
Copy link
Collaborator

Allda commented May 15, 2024

@grokspawn Based on your PoC we created an official version that will be available to both community and isv users.
redhat-openshift-ecosystem/operator-pipelines#653

I'll close this PR but if you think it is still relevant please let me know.

@Allda Allda closed this May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants