Catalog update [v4.18,v4.16,v4.17,v4.13,v4.14,v4.15]

[zdtsw]

• update reviewer list

Thanks for submitting your Operator. Please check the below list before you create your Pull Request.

New Submissions

• Are you familiar with our contribution guidelines?
• Are you familiar with our operator pipeline?
• Have you tested your Operator with all Custom Resource Definitions packaging?
• Have you tested your Operator in all supported installation modes?
• Have you considered whether you want to use semantic versioning order?
• Is your submission signed?
• Is operator icon set?

Your submission should not

• Add more than one operator bundle per PR
• Modify any operator
• Rename an operator
• Modify any files outside the above mentioned folders
• Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

1. Description of the managed Application and where to find more information
2. Features and capabilities of your Operator and how to use it
3. Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

• Human readable name and 1-liner description about your Operator
• Valid category name¹
• One of the pre-defined capability levels²
• Links to the maintainer, source code and documentation
• Example templates for all Custom Resource Definitions intended to be used
• A quadratic logo

Remember that you can preview your CSV here.

--

¹ If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need

² For more information see here

[zdtsw]

FYI @VaishnaviHire @lburgazzoli

[zdtsw]

mark it as a draft, no need merge it now, only as preparation

[rh-operator-bundle-bot]

Pipeline Summary

Pipeline: operator-hosted-pipeline
PipelineRun: operator-hosted-pipeline-run2nmk6
Start Time: 2024-10-02 15:45:13+00:00

Tasks

Status	Task	Start Time	Duration
✔️	get-pr-number	2024-10-02 15:45:15+00:00	6 seconds
✔️	acquire-lease	2024-10-02 15:45:27+00:00	6 seconds
✔️	set-github-started-label	2024-10-02 15:45:38+00:00	10 seconds
✔️	set-github-status-pending	2024-10-02 15:45:50+00:00	7 seconds
✔️	set-env	2024-10-02 15:46:01+00:00	6 seconds
✔️	clone-repository	2024-10-02 15:46:11+00:00	41 seconds
✔️	clone-repository-base	2024-10-02 15:46:11+00:00	43 seconds
✔️	detect-changes	2024-10-02 15:46:58+00:00	53 seconds
✔️	check-permissions	2024-10-02 15:47:54+00:00	48 seconds
✔️	set-github-pr-title	2024-10-02 15:48:44+00:00	8 seconds
✔️	read-config	2024-10-02 15:48:56+00:00	36 seconds
✔️	resolve-pr-type	2024-10-02 15:49:35+00:00	7 seconds
✔️	validate-catalog-format	2024-10-02 15:49:46+00:00	41 seconds
✔️	build-fragment-images	2024-10-02 15:50:29+00:00	a minute
✔️	content-hash	2024-10-02 15:51:35+00:00	32 seconds
✔️	certification-project-check	2024-10-02 15:52:10+00:00	35 seconds
✔️	get-organization	2024-10-02 15:52:48+00:00	49 seconds
✔️	get-pyxis-certification-data	2024-10-02 15:53:39+00:00	41 seconds
✔️	static-tests	2024-10-02 15:54:25+00:00	40 seconds
✔️	static-tests-results	2024-10-02 15:55:12+00:00	16 seconds
✔️	merge-registry-credentials	2024-10-02 15:55:33+00:00	15 seconds
✔️	digest-pinning	2024-10-02 15:55:52+00:00	46 seconds
✔️	verify-pinned-digest	2024-10-02 15:56:41+00:00	7 seconds
✔️	dockerfile-creation	2024-10-02 15:56:50+00:00	33 seconds
✔️	build-bundle	2024-10-02 15:57:30+00:00	41 seconds
✔️	get-supported-versions	2024-10-02 15:58:18+00:00	42 seconds
✔️	build-fbc-index-images	2024-10-02 15:59:05+00:00	11 minutes
✔️	get-ci-results-attempt	2024-10-02 16:10:06+00:00	18 seconds
✔️	preflight-trigger	2024-10-02 16:10:25+00:00	18 seconds
✔️	get-ci-results	2024-10-02 16:10:44+00:00	16 seconds
✔️	link-pull-request-with-open-status	2024-10-02 16:11:03+00:00	7 seconds
✔️	merge-pr	2024-10-02 16:11:14+00:00	42 seconds

Pipeline logs: https://gist.github.com/rh-operator-bundle-bot/0a344f8f69e0b5d2412dabb17d87f74d

❌ Not merged

PR cannot be merged for the following reasons: Pull Request is still a draft (mergePullRequest)

Troubleshooting

Please refer to the troubleshooting guide.

Run /pipeline restart operator-hosted-pipeline in case of pipeline failure to restart a pipeline.

[zdtsw]

@Allda could you help me understand:
after onboarding (this PR) what will need for the next release?
assume we are going to have a 2.19.0 release, according to https://olm.operatorframework.io/docs/advanced-tasks/catalog-update-formulary/#fbc
we only need to run something like
yq eval 'select(.schema=="olm.channel" and .name == "fast").entries += [{"name" : "opendatahub-operator.v2.19.0", "replaces": "opendatahub-operator.v2.18.2", "skipRange": "'>=1.0.0 <2.19.0", "skips": ["opendatahub-operator.v2.9.0"]}]' catalogs/v${version}/opendatahub-operator/catalog.yaml => here version will be a loop of 4.12 4.13 4.14 4.15.4.16 ?
is that enough?
what about these schema: olm.bundle entries with olm.bundle.object, how do they get updated ?
or am i totally in the wrong direction, that we should change catalog-templates/* instead then run opm to generate catalog.yaml

[mporrato]

@zdtsw once this is merged, to publish a new bundle you will have to submit a PR to add the new bundle (i.e.: operators/opendatahub-operator/2.19.0) just like you used to do before. Once the PR is merged, you can submit a second PR to update the catalogs: you do this by editing the catalog-template files depending on which channels you want to make the new bundle available and run make catalogs to automatically update the files under catalogs/: for example, for 2.19.0 you may want to add something like

  - name: opendatahub-operator.v2.19.0
    replaces: opendatahub-operator.v2.18.2
    skipRange: '>=1.0.0 <2.19.0'
    skips:
    - opendatahub-operator.v2.9.0

to your olm.channel sections and

- image: quay.io/community-operator-pipeline-prod/opendatahub-operator:2.19.0
  schema: olm.bundle

to the root level olm.template.basic section.
BTW, you probably should include the Makefile in this PR.
Let me know if this is not clear enough.

[zdtsw]

@zdtsw once this is merged, to publish a new bundle you will have to submit a PR to add the new bundle (i.e.: operators/opendatahub-operator/2.19.0) just like you used to do before. Once the PR is merged, you can submit a second PR to update the catalogs: you do this by editing the catalog-template files depending on which channels you want to make the new bundle available and run make catalogs to automatically update the files under catalogs/: for example, for 2.19.0 you may want to add something like

  - name: opendatahub-operator.v2.19.0
    replaces: opendatahub-operator.v2.18.2
    skipRange: '>=1.0.0 <2.19.0'
    skips:
    - opendatahub-operator.v2.9.0

to your olm.channel sections and

- image: quay.io/community-operator-pipeline-prod/opendatahub-operator:2.19.0
  schema: olm.bundle

to the root level olm.template.basic section. BTW, you probably should include the Makefile in this PR. Let me know if this is not clear enough.

Thanks @mporrato think I've grabbed the idea.
some more questions:

• this change of using FBC will make the original work process from "submit 1 PR" to "submit 2 PRs"
• the updates in the 2nd PR with olm.bundle.image should be the operator image with tag but stored in quay.io/community-operator-pipeline-prod/ ? (is this image somehow populated after the 1st PR gets merged)
• checked-in Makefile is only used by us when generate the 2nd PR? (and we need to maintain the valid ocp version in the list)

[rh-operator-bundle-bot]

Pipeline Summary

Pipeline: operator-hosted-pipeline
PipelineRun: operator-hosted-pipeline-runswnfs
Start Time: 2024-10-07 09:51:18+00:00

Tasks

Status	Task	Start Time	Duration
✔️	get-pr-number	2024-10-07 09:51:20+00:00	8 seconds
✔️	acquire-lease	2024-10-07 09:51:32+00:00	7 seconds
✔️	set-github-started-label	2024-10-07 09:51:43+00:00	11 seconds
✔️	set-github-status-pending	2024-10-07 09:51:57+00:00	9 seconds
✔️	set-env	2024-10-07 09:52:10+00:00	9 seconds
✔️	clone-repository	2024-10-07 09:52:24+00:00	32 seconds
✔️	clone-repository-base	2024-10-07 09:52:24+00:00	36 seconds
✔️	detect-changes	2024-10-07 09:53:03+00:00	46 seconds
✔️	check-permissions	2024-10-07 09:53:52+00:00	38 seconds
✔️	set-github-pr-title	2024-10-07 09:54:32+00:00	9 seconds
✔️	read-config	2024-10-07 09:54:44+00:00	39 seconds
✔️	resolve-pr-type	2024-10-07 09:55:27+00:00	7 seconds
✔️	validate-catalog-format	2024-10-07 09:55:38+00:00	45 seconds
✔️	build-fragment-images	2024-10-07 09:56:25+00:00	48 seconds
✔️	content-hash	2024-10-07 09:57:14+00:00	13 seconds
✔️	certification-project-check	2024-10-07 09:57:30+00:00	43 seconds
✔️	get-organization	2024-10-07 09:58:16+00:00	37 seconds
✔️	get-pyxis-certification-data	2024-10-07 09:58:55+00:00	35 seconds
✔️	static-tests	2024-10-07 09:59:31+00:00	13 seconds
✔️	static-tests-results	2024-10-07 09:59:45+00:00	10 seconds
✔️	merge-registry-credentials	2024-10-07 09:59:58+00:00	24 seconds
✔️	digest-pinning	2024-10-07 10:00:25+00:00	48 seconds
✔️	verify-pinned-digest	2024-10-07 10:01:15+00:00	7 seconds
✔️	dockerfile-creation	2024-10-07 10:01:24+00:00	48 seconds
✔️	build-bundle	2024-10-07 10:02:13+00:00	12 seconds
✔️	get-supported-versions	2024-10-07 10:02:26+00:00	13 seconds
✔️	build-fbc-index-images	2024-10-07 10:02:40+00:00	11 minutes
✔️	get-ci-results-attempt	2024-10-07 10:14:13+00:00	13 seconds
✔️	preflight-trigger	2024-10-07 10:14:27+00:00	27 seconds
✔️	get-ci-results	2024-10-07 10:14:57+00:00	23 seconds
✔️	link-pull-request-with-open-status	2024-10-07 10:15:25+00:00	8 seconds
✔️	merge-pr	2024-10-07 10:15:36+00:00	40 seconds

Pipeline logs: https://gist.github.com/rh-operator-bundle-bot/fbf32fdb522043372d730da105ad2fcd

❌ Not merged

PR cannot be merged for the following reasons: Pull Request is still a draft (mergePullRequest)

Troubleshooting

Please refer to the troubleshooting guide.

Run /pipeline restart operator-hosted-pipeline in case of pipeline failure to restart a pipeline.

[mporrato]

@zdtsw

1. Yes, publishing a new bundle will be a two step process from now on. If for any reason you have multiple bundles to release, you can instead submit N PRs (one for each bundle) and a single final PR to update the catalog templates: the idea is that the bundle images you list in your catalog templates must already exist for the catalog update to be processed correctly.
2. The bundle images in quay.io/community-operator-pipeline-prod/ are created when the first PR is merged
3. The Makefile is used by you to automatically render the catalogs based on your catalog templates but is also updated by our automation when a new ocp version is bootstrapped if you opt into the automated catalog promotion process.