k8s-operatorhub / community-operators

The canonical source for Kubernetes Operators that are published on OperatorHub.io and part of the default catalog of the Operator Lifecycle Manager.

Kubernetes Community Operators

About this repository

This repo is the canonical source for Kubernetes Operators that appear on OperatorHub.io. The solutions merged on this repository are distributed via the OLM index catalog quay.io/operatorhubio/catalog. Users can install OLM in any Kubernetes or vendor such as Openshift to consume this content by adding a new CatalogSource for the index image quay.io/operatorhubio/catalog. (more info)

NOTE If you are looking to distribute solutions on Openshift/OKD catalog then, you also should publish them into the repository Community Operators.

Documentation

Full documentation is generated via mkdoc and is located at https://k8s-operatorhub.github.io/community-operators/

IMPORTANT NOTICE

Some APIs versions are deprecated and are OR will no longer be served on the Kubernetes version 1.22/1.25/1.26 and consequently on vendors like Openshift 4.9/4.12/4.13.

What does it mean for you?

Operator bundle versions using the removed APIs can not work successfully from the respective releases. Therefore, it is recommended to check if your solutions are failing in these scenarios to let its users be aware. Note that you can inform via the CSV the minimal (spec.minKubeVersion) and the max Kubernetes version (metadata.annotation operatorhub.io/ui-metadata-max-k8s-version) where your solution can successfully work. This information can be checked on the details of each release on OperatorHub.io.

Please, make sure you check the following announcements:

• How to deal with removal of v1beta1 CRD removals in Kubernetes 1.22
• Kubernetes API removals on 1.25/1.26 might impact your Operator. How to deal with it?

NOTE If you have been distributing solutions on Openshift you might be aware of the property "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "<OCP version>"}]' which can be used to block cluster admins upgrades when they have Operator versions installed that can not work well in OCP versions higher than the value informed. Nothing prevents you from using this property here, however, be aware that it is ignored on OperatorHub.io and that the index catalog built from this repository is not part of the Openshift catalog. So that, it can be useful only for those who are creating a new Source Catalog on Openshift using the index image: quay.io/operatorhubio/catalog:latest.

Reporting Bugs

Use the issue tracker in this repository to report bugs.

community-operators's Issues

YAML example for dell-csm-operator CRD is missing few fields. How can that be corrected

Discussed in https://github.com/k8s-operatorhub/community-operators/discussions/1008

^{Originally posted by rensyct March 30, 2022}
YAML example for dell-csm-operator CRD is missing two fields. How can that be corrected? Samples are corrected and image is updated to have the correct entries. What step should be taken next so that OperatorHub will show the updated sample yaml files for the CRD

clickhouse operator included in github, but missing on operatorhub.io

Hi there! Observe strange situation - how does it happen that clickhouse-operator it present in github repo https://github.com/k8s-operatorhub/community-operators/tree/main/operators/clickhouse but is missing on operatorhub?

operators dell-csi-operator: Some files are not updated for v1.7.0 as previous version (v1.6.0) is getting installed

Latest version of dell-csi-operator is v1.7.0. PR for the same is #960
Followed the instructions to install dell-csi-operator on a K8s environment with OLM installed.
But kubectl create -f https://operatorhub.io/install/dell-csi-operator.yaml installs the previous version (v1.6.0) of dell-csi-operator

Expected behaviour - kubectl create -f https://operatorhub.io/install/dell-csi-operator.yaml should install the latest version of dell-csi-operator which is v1.7.0

PR title expects "operators" instead of "operator"

This repo expects the PR titles to start with "operators" instead of "operator". This makes it inconsistent with other repositories such as https://github.com/redhat-openshift-ecosystem/certified-operators.
The term "operator" seems to be a more accurate and would provide some convenience when submitting.

OperatorHub temporary tags will be removed

📢 OperatorHub temporary tags will be removed

To help the community we provide temporary tags to offer an extended period for users to begin to consume the OperatorHub catalog index image using the new format (FBC). However, the extended time expired and we would like to let you know that these tags will no longer be produced and will be removed due April 19th.

💁 What does this mean for you:

The temporary tmp_latest_fbc and tmp_latest_sql tags will no longer be served. If you are using these ones please ensure that you can consume the production quay.io/operatorhubio/catalog:latest tag provided by the OperatorHub catalog. It already has the new format (FBC).

✨ You are NOT impacted:

If you are just contributing to the OperatorHub catalog via PRs or consuming this index image in OLM or vendors like Openshift. Nothing changes for you. As far as you don't use special setup where you are pointing to an index image tag containing tmp_latest in the name.

More info: #505

Error: error loading bundle into db: FOREIGN KEY constraint failed

Hi we are getting failure with the following pr #1193 testing: https://github.com/k8s-operatorhub/community-operators/runs/6351359872?check_suite_focus=true
can you please advice us what is the cause for this issue?
is it because we are using packagemanifest instead of bundle in the packaging format?
We update the following annotation: olm.maxOpenShiftVersion",from 3.9 to 4.10

Multiarch support

Hi,

We been adding multi-arch support to our cloud-native-postgresql operator in the past few days but we hit a few bugs that were fixed on https://github.com/operator-framework/operator-registry but in community-operators the catalog is created using the old image upstream-registry-builder which is reported as deprecated since it use deprecated apps operator-framework/operator-registry#805

Possible solution, is it possible to switch and use the latest operator-registry/opm image? We can propose a PR but we don't really know if the community-operators wants to update that.

Our understanding is that we just need to update this Dockerfile https://github.com/k8s-operatorhub/community-operators/blob/main/upstream.Dockerfile if that's right we can propose an update.

Best Regards,

YAML example for dell-csm-operator CRD is missing few fields. How can that be corrected

Discussed in https://github.com/k8s-operatorhub/community-operators/discussions/1008

^{Originally posted by rensyct March 31, 2022}
YAML example for dell-csm-operator CRD was missing two fields. How can that be corrected? Samples are corrected and image is updated to have the correct entries. What step should be taken next so that OperatorHub will show the updated sample yaml files for the CRD

I am converting this to an issue as I did not get any response in Q&A discussion thread. PR link - #964

Skipping e2e for tektoncd-operator (0.60.0)

I was trying to release latest version for tektoncd-operator for operator hub but am not able to pass the CI.
Pull req : #1424

with tektoncd-operator, we package multiple CRDs, one of which is TektonInstallerSet
when operator is installed, it internally creates an instance of TektonInstallerSet for some internal resources.

now in CI, after installation, it removes deployments and then CRDs
while removing TektonInstallerSet CRD it gets blocked as instance is already on cluster with finalizer set
and as deployments are already deleted, it will blocks indefinitely
so the deletion of CRD is getting timeout

is there any way I can override CI script or skip the e2e in this case?
or any other suggestion?

Bundle merged cannot be load by the operator-framework/api

Description
The following distribution cannot be load via operator-framework/api
https://github.com/k8s-operatorhub/community-operators/blob/main/operators/litmuschaos/1.9.0/

Error: unable to parse CRD chaosengines.litmuschaos.io.crd.yaml: error converting YAML to JSON: yaml: line 81: could not find expected ':',

This issue is probably raised when we try to migrate the package manifest to bundle. Then, it shows for me that we need:

a) Contact the author to fix the manifest
b) Ensure that in the ci/pipeline we:

• Ensure that we raise errors if we are unable to convert the pkg to bundle
• Check if we are calling in the CI/Pipeline operator-sdk bundle validate ./bundle --select-optional name=operatorhub to ensure the distributions.

nfd-operator: update to v0.3.0

Operatorhub still shows the ancient v0.2.0. We need to update to v0.3.0 ASAP

/assign ArangoGutierrez

metadata.annotations.containerImage got mandatory?

The checks for SBO recent submission failed reporting that metadata.annotations.containerImage is not found on CSV. All previous SBO CSVs do not have it, and validating the bundle with operator-sdk did not report any issues:

operator-sdk bundle validate ./bundle --select-optional name=operatorhub

Used operator-sdk 1.3

operator release pipeline is failing at OHIO stage

https://github.com/k8s-operatorhub/community-operators/actions/runs/2494848835

Document how to deprecate an operator

In #529 the hazelcast-operator has been deprecated by adding a [DEPRECATED] prefix to its name, but is this the recommended process?

On operatorhub.io, this has the effect of showing the deprecated operators first:

• #549
• k8s-operatorhub/operatorhub.io#13

Some of the documentation mentions a maturity: deprecated field / value pair, but does not elaborate further:

• https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/building-your-csv.md#operator-metadata
• https://docs.okd.io/4.9/operators/operator_sdk/osdk-generating-csvs.html#osdk-manually-defined-csv-fields_osdk-generating-csvs

(It is confusing that the word "maturity" is used elsewhere in reference to metadata.capabilities and Operator Capabilities)

I'd like some documentation recommending when and how to deprecate an operator.

More power for authorized users in self-service community operators

Self-service community operator version PRs are way cool!

However, a handful of things I've noticed that would make it even cooler:

• When adding an authorized user to ci.yaml (e.g. 1, 2), a repo admin still needs to participate to get the PR merged. It would be cool if pre-existing reviewers in ci.yaml could have that power (via /lgtm or /approve or whatever).
• When a test fails, even an authorized (via ci.yaml) user can't seem to retest or add ok-to-test.

Location of community-operators index image is not documented

On operatorhub.io, the location of the community-operators index image is not documented anywhere. This makes it challenging for operator authors to test their bundles if their ClusterServiceVersion depends on other APIs, and therefore the test catalog needs to contain an operator bundle which provides the referenced APIs.

Please provide the location of where the index image is published, and/or the locations of the bundle images build from this repository.

Bump SDK and replace ansible check

See the following error.
https://github.com/k8s-operatorhub/community-operators/runs/5113897313?check_suite_focus=true#step:6:718

We should bump SDK 1.17.0 and remove this ansible playbook check now that the test is done by SDK. See: operator-framework/operator-sdk#5495

Please update the spark-on-k8s operator

The spark-on-k8s by GoogleCloudPlatform is very old (2019) and won't be compatible with OCP 4.9.

Can you please update it?

Best regards

camel-k floating tags have been deleted

Whether it was due to PR #835 or something else all the floating tags of camel-k version have been deleted in the catalog. Are they due to be recreated?

PR-traffic-light fails on curl tinyurl Download dyff

TASK [install_operator_prereqs : Download yq (2.2.1)] **************************
changed: [localhost]

TASK [install_operator_prereqs : Create directory '/home/runner'] **************
ok: [localhost]

TASK [install_operator_prereqs : Download dyff] ********************************
fatal: [localhost]: FAILED! => changed=true
cmd: curl --silent --location https://tinyurl.com/y4qvdl4d | bash
delta: '0:00:00.058416'
end: '2021-11-18 09:34:13.954241'
failed_when_result: true
msg: non-zero return code
rc: 2
start: '2021-11-18 09:34:13.895825'
stderr: |-
bash: line 1: syntax error near unexpected token newline' bash: line 1: '
stderr_lines:
stdout: ''
stdout_lines:

PLAY RECAP *********************************************************************
localhost : ok=14 changed=5 unreachable=0 failed=1 skipped=5 rescued=0 ignored=0

Error: Process completed with exit code 2.

Support for persistent volume mounted to Operator

Hello, We are working on splunk operator. version 2.0.0 of splunk operator requires persistent volume to be mounted to splunk operator deployment. but bundle creation using olm do not allow persistent volume creation. How can I support in bundle certification for community operator to create persistent volume when I create PR for running any actions.

Update the readme to clarifies where and how this repo is used

We need to add into the readme:

• That the image built from the projects merged here is quay.io/operatorhubio/catalog:latest
• Clarifies that this repository is used to create the website and the image
• Clarifies that the solutions merged here ought to work in the k8s cluster but also terically can be used in its vendor
• That the image built is not used in OCP or OKD and add the link for https://github.com/redhat-openshift-ecosystem/community-operators-prod to let the users know where they should push their solutions if they are looking for distributed their solutions by default in these vendors
• Also, we need to add the steps over how to consume this source in OLM ( k8s cluster via command line ) and in OCP/OKD via console/UI.

Couchdb operator issue: not saving settings

I have couchdb installed on an eks cluster, I have a problem every time the POD is restarted or deleted, the configuration is lost.
So far I haven't found any solution that saves the configuration even when the cluster is restarted.
The only thing that comes close to a solution is to add referenced fields to the configuration, however this option does not allow adding all the fields of the configuration.

https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-configure-couchdb-cluster

Can we extend the timeout of 60s for cleanup

TASK [cleanup_operator_resources : Delete all processed resources in the deploy directory] ***
changed: [localhost] => (item=/tmp/operator-test/olm-operator-files/subscription.yml)
changed: [localhost] => (item=/tmp/operator-test/olm-operator-files/catalogsource.yml)
changed: [localhost] => (item=/tmp/operator-test/olm-operator-files/catalogsource-prod.yml)
failed: [localhost] (item=/tmp/operator-test/olm-operator-files/namespace.yml) => changed=true 
  ansible_loop_var: cor_all_yml_item
  cmd: kubectl delete -f /tmp/operator-test/olm-operator-files/namespace.yml --ignore-not-found=true --timeout=60s
  cor_all_yml_item: /tmp/operator-test/olm-operator-files/namespace.yml
  delta: '0:01:00.073248'
  end: '2022-04-28 14:43:25.038989'
  msg: non-zero return code
  rc: 1
  start: '2022-04-28 14:42:24.965741'
  stderr: 'error: timed out waiting for the condition on namespaces/test-operators'
  stderr_lines: <omitted>
  stdout: namespace "test-operators" deleted
  stdout_lines: <omitted>
changed: [localhost] => (item=/tmp/operator-test/olm-operator-files/operatorgroup.processed.yml)

This is the issue I ran into for testing knative operator.
It happened most of the time, but after a few times of retesting, it goes away.

I suspect that 60s could be a little shorter. Can we extend the timeout for cleanup to 180s? or even 300s?

knative-operator 1.4.0 fail initial install

HI

@houshengbo

with new release of operator knative (1.4.0)

the installation fail because the container operator-webhook is absent and webhook is declared in CSV

Orange test is failing and throw 401 UNAUTHORIZED for "community-operators-pipeline" repository

Hi,

• Suddenly today our job with orange tests has been failed using this script https://raw.githubusercontent.com/redhat-openshift-ecosystem/community-operators-pipeline/ci/latest/ci/scripts/opp.sh and guide https://k8s-operatorhub.github.io/community-operators/operator-test-suite/

• The same job was always successful all the time.

Here is the log:

TASK [test_operator_update : Show sdk version] ********************************* changed: [localhost]

TASK [test_operator_update : Installing quay.io/community-operators-pipeline/hazelcast-platform-operator:v5.2.0] ***
fatal: [localhost]: FAILED! => changed=true 
  cmd: /tmp/operator-test/bin/operator-sdk run bundle quay.io/community-operators-pipeline/hazelcast-platform-operator:v5.2.0 --skip-tls-verify
  delta: '0:00:00.534628'
  end: '2022-04-26 19:44:35.747175'
  msg: non-zero return code
  rc: 1
  start: '2022-04-26 19:44:35.212547'
  stderr: 'time="2022-04-26T19:44:35Z" level=fatal msg="Failed to run bundle: pull bundle image: error pulling image quay.io/community-operators-pipeline/hazelcast-platform-operator:v5.2.0: error resolving name : unexpected status code [manifests v5.2.0]: 401 UNAUTHORIZED\n"'
  stderr_lines: <omitted>
  stdout: ''
  stdout_lines: <omitted>
...ignoring

TASK [test_operator_update : Testing operator upgrade from quay.io/community-operators-pipeline/hazelcast-platform-operator:v5.2.0 to kind-registry:5000/test-operator/hazelcast-platform-operator:v8.8.8] ***
fatal: [localhost]: FAILED! => changed=true 
  cmd: /tmp/operator-test/bin/operator-sdk run bundle-upgrade kind-registry:5000/test-operator/hazelcast-platform-operator:v8.8.8 --skip-tls-verify
  delta: '0:00:00.189973'
  end: '2022-04-26 19:44:36.171663'
  msg: non-zero return code
  rc: 1
  start: '2022-04-26 19:44:35.981690'
  stderr: 'time="2022-04-26T19:44:36Z" level=fatal msg="Failed to run bundle upgrade: no existing operator found in the cluster to upgrade\n"'
  stderr_lines: <omitted>
  stdout: ''
  stdout_lines: <omitted>
...ignoring

New operator Datatrucker.io

DataTrucker.IO is a new operator which can help build API backends with less/no code CRDs

Website : https://www.datatrucker.io/

Unable to upgrade cert-manager from 1.4.0 to 1.4.3

I first reported this in operator-framework/kubectl-operator#53 (comment) where @joelanford replied:

It looks like your operator is configured to use semver mode, so I would have expected the upgrade edges to use replaces, not skips. I tried re-creating the database with opm to see if opm is to blame for this, but it doesn't seem to be:
...
From OLM's perspective, the root cause here is that skips are not transitive. The only bundle that has an upgrade edge from 1.4.0 is 1.4.1, but since 1.4.1 is skipped by 1.4.2, the OLM resolver eliminates 1.4.1 as a candidate, leaving no viable candidates.

This could be solves by using replaces instead of skips, or by having all the previous versions skipped by the newer versions.

Can you file an issue in github.com/k8s-operatorhub/community-operators asking why skips are being used for semver-mode instead of replaces?

I recently added a series of patch releases for cert-manager, both here and in the https://github.com/redhat-openshift-ecosystem/community-operators-prod repo and upon testing the upgrades using kubectl operator I found that the upgrade got stuck when ever I tried upgrading across more than one patch release.

Adding CatalogSource

Discussed in https://github.com/k8s-operatorhub/community-operators/discussions/1044

^{Originally posted by dkoci April 12, 2022}
Hi.
I would like access operators from operatorhub.io in my okd cluster. I have to create a CatalogSource. Which is the correct image? I found quay.io/operator-framework/upstream-community-operators:latest, but it doesnt work.

Tnx

prometheus operator is out of date 0.47.0 vs 0.54.0

The upstream prometheus operator is many releases ahead of the what is available in operatorhub. Can we get a new release cut here please?

https://github.com/prometheus-operator/prometheus-operator/releases

OperatorHub doc update

Hi,

I think the How to contribute an Operator doc should be updated due to this repos change. The doc it pointing to the old repo.

Alphabetical sorting on operatorhub.io is putting deprecated operators first

Looking at operatorhub.io, the top looks like this:

My first-blush reaction was that operatorhub.io itself had been deprecated, which is an unfair reaction driven by my having lived through the github.com/helm/charts deprecation...

Anyway, I assume the underlying cause is that alphabetically, [ sorts before A, and there's no rule preventing naming your operator to (intentionally or unintentionally) take advantage of that.

Putting [Deprecated] at the start of the name of a deprecated operator's entry isn't ideal, but there isn't a "deprecated" field or similar in ClusterServiceVersion v1alpha1 that could be used specifically for this.

Perhaps recognising a deprecated value for the maturity free-string field would work? Or perhaps this is something that should be at the channel level instead, to deprecate a whole operator, rather than a specific version?

Anyway, with that metadata being distinguished, then deprecated operators could be hidden by default, and searched as a separate axis, and the deprecation status could be made visible via something other than the name field.

Percona Postgres operator install mode

Hello,

in the clusterserviceversion file of the Percona Postgres Operator, the supported installMode is only OwnNamespace :
https://github.com/k8s-operatorhub/community-operators/blob/main/operators/percona-postgresql-operator/1.2.0/percona-postgresql-operator.v1.2.0.clusterserviceversion.yaml#L224

But, in the Percona Repo, it supports other modes:
https://github.com/percona/percona-postgresql-operator/blob/main/installers/olm/postgresoperator.csv.yaml#L59

Is it possible to allow all supported modes ?

Rgds.

docker build of upstream.Dockerfile fails

docker image build with upstream.Dockerfile fails at

community-operators/upstream.Dockerfile

Line 3 in 03e9cad

COPY upstream-community-operators manifests

Should it be just COPY operators manifests instead of COPY upstream-community-operators manifests ?

[operators/prometheus] cant monitor outside his namespace

As I already described here prometheus cant monitor outside of his namespace.

could you please change in the csv of the operator args from this:

        - -namespaces=$(NAMESPACES)

to this:

        - --prometheus-instance-namespaces=$(NAMESPACES)
        - --alertmanager-instance-namespaces=$(NAMESPACES)
        - --thanos-ruler-instance-namespaces=$(NAMESPACES)

and also the promehteus easily exeeding his resources, so could you please also edit the resources from this:

resources:
  limits:
    cpu: 200m
    memory: 200Mi
  requests:
    cpu: 100m
    memory: 100Mi

to this:

resources:
  limits:
    cpu: 300m
    memory: 3Gi
  requests:
    cpu: 100m
    memory: 100Mi

in here and here

Index image quay.io/operatorhubio/catalog:latest missing label operators.operatorframework.io.index.database.v1

Hi,
To test the installation of CSI, we run the following command, for v1.19.5 opm version:

opm index add --bundles <image> --from-index quay.io/operatorhubio/catalog:latest --tag <image>

As of February 2, we started getting the following error:

Error: index image quay.io/operatorhubio/catalog:latest missing label operators.operatorframework.io.index.database.v1

Could you assist with that?

CI pipeline prevents Minor Cosmetic Changes

In #722 I expected label changes to be accepted as Minor Cosmetic Changes

I realise that that document doesn't include label changes in this category, but I put that down to incomplete documentation.
The reason I thought that, is that an identical PR was submitted by @yselkowitz in redhat-openshift-ecosystem/community-operators-prod#434 and merged after passing all the CI checks.

And I can see that this PR has been labelled allow/operator-recreate.

Have I understood correctly?

What do you think?

Originally posted by @wallrj in #722 (comment)

Remove Sysdig Operator

Hello I wanted to know the process of removing an operator from the k8s operatorhub? The maintainer is no longer with us, and the operator is outdated.

[test_operator_update : Logs] should be skipped if no update is being performed

From PR: #1212
In test: orange / Deploy k8s (latest)

Currently, I am placing a new MinIO Operator version in this repository, but in operators/minio-operator/ci.yaml I am explicitly putting updateGraph: semver-mode so no replace is being implemented. I even see some skips/ignores on previous tests like:

TASK [test_operator_update : Testing operator upgrade from quay.io/operatorhubio/minio-operator:v4.4.17 to kind-registry:5000/test-operator/minio-operator:v4.4.17] ***

TASK [test_operator_update : Installing quay.io/operatorhubio/minio-operator:v4.4.17] ***

But for some reason TASK [test_operator_update : Logs] test is failing because no pod is being provided, maybe we should ignore or skip this test if no update is being requested:

TASK [test_operator_update : Logs] *********************************************
fatal: [localhost]: FAILED! => changed=true 
  cmd: kubectl logs  -n default
  delta: '0:00:00.054616'
  end: '2022-05-16 20:59:40.408130'
  msg: non-zero return code
  rc: 1
  start: '2022-05-16 20:59:40.353514'
  stderr: |-
    error: expected 'logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER]'.
    POD or TYPE/NAME is a required argument for the logs command
    See 'kubectl logs -h' for help and examples
  stderr_lines: <omitted>
  stdout: ''
  stdout_lines: <omitted>

Or perhaps get the logs from proper pod, please help me to correct this issue or guide on what I should do to update this Pull Request to avoid that issue.

Thank you very much team for your help and support! 👍

CI KIWI test is now using kube 1.21, not 1.22

There is a revert of the kube version of he kiwi ci test.
It was using 1.21, but later changed to use 1.22, so knative operator can pass.
But now it is back to use kube 1.21.

@mvalarh

community-operators usage data

Hey,

we have 2 different operators released here and we would like to get some usage data.
Is there a way to track the amount of views / clicks on the 'Install' button to get a rough feeling about the usage?

Thanks,
Marco

Would like to change the name of a category, what is the process for that?

Hello, we'd like to update a name of a migration category from "Modernization & Migration" to "Migration and Modernization". Could someone help me understand what the process for that change would be, and what kind of approvals are necessary in order to apply that change?

Somehow these community operator categories are also shared by downstream OpenShift operators, see screenshot:

If a downstream operator specifies a Category that is also shared by the Categories specified here, will OLM simply merge them into the same category? Who are the right people to reach out to to ask these questions? I'm also available at ernelson redhat com since this issue seems to straddle both upstream operatorhub and downstream.

etcd operator Install fails on k8s 1.22 - use of depcrecated api apiextensions.k8s.io/v1beta1 no longer served

The apiextensions.k8s.io/v1beta1 API version of CustomResourceDefinition is no longer served as of k8s v1.22.

Migrate manifests and API clients to use the apiextensions.k8s.io/v1 API version, available since v1.16.
All existing persisted objects are accessible via the new API

see: https://kubernetes.io/docs/reference/using-api/deprecation-guide/

The olm subscription indicates the failure with the following

lastUpdated: "2021-10-20T19:26:20Z"
conditions:
- lastTransitionTime: "2021-10-20T19:26:20Z"
message: all available catalogsources are healthy
reason: AllCatalogSourcesHealthy
status: "False"
type: CatalogSourcesUnhealthy
- status: "False"
type: ResolutionFailed
- lastTransitionTime: "2021-10-20T19:44:42Z"
message: 'api-server resource not found installing CustomResourceDefinition
etcdbackups.etcd.database.coreos.com: GroupVersionKind apiextensions.k8s.io/v1beta1,
Kind=CustomResourceDefinition not found on the cluster. This API may have
been deprecated and removed, see https://kubernetes.io/docs/reference/using-api/deprecation-guide/
for more information.'

message: 'api-server resource not found installing CustomResourceDefinition
etcdbackups.etcd.database.coreos.com: GroupVersionKind apiextensions.k8s.io/v1beta1,
Kind=CustomResourceDefinition not found on the cluster. This API may have
been deprecated and removed, see https://kubernetes.io/docs/reference/using-api/deprecation-guide/
for more information.'

Failed local tests - op_index.yml

Running:

OP_TEST_DEBUG=3 bash <(curl -sL https://raw.githubusercontent.com/redhat-openshift-ecosystem/community-operators-pipeline/ci/latest/ci/scripts/opp.sh) kiwi,lemon,orange operators/seldon-operator/1.12.0

I get

TASK [operator_index : Set versions and versions_bt] ***************************
task path: /playbooks/upstream/roles/operator_index/tasks/op_index.yml:64
fatal: [localhost]: FAILED! => 
  msg: |-
    The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'latest'
  
    The error appears to be in '/playbooks/upstream/roles/operator_index/tasks/op_index.yml': line 64, column 3, but may
    be elsewhere in the file depending on the exact syntax problem.
  
    The offending line appears to be:
  
  
    - name: "Set versions and versions_bt"
      ^ here

PLAY RECAP *********************************************************************
localhost                  : ok=1006 changed=102  unreachable=0    failed=1    skipped=945  rescued=0    ignored=2   

Its very unclear how to solve this. Any ideas?

Its running in the image

quay.io/operator_testing/operator-test-playbooks:latest

I don't see this ansible script in https://github.com/redhat-openshift-ecosystem/operator-test-playbooks

The output whole output of the tests called using SDK are red which brings confusion

See that the output whole output of the tests called using SDK is red which brings confusion.
It is very hard for contributors to identify what is a WARNING and what is an error.

So, could we change it to only output in red what is an ERROR and in yellow what is a WARN?

c/c @mvalarh @J0zi

Error in Operator Release workflow: operator was not published on operatorhub.io after it merged

I merged

• #780

but it didn't get published to operatorhub.io

The Operator Release workflow failed

TASK [operator_index : Add 'couchbase-enterprise' operator to index image quay.io/operatorhubio/catalog_tmp:latest] ***
...
time="2022-02-16T22:14:37Z" level=error msg="permissive mode disabled" bundles="[quay.io/operatorhubio/couchbase-enterprise:v1.0.0 quay.io/operatorhubio/couchbase-enterprise:v1.1.0 quay.io/operatorhubio/couchbase-enterprise:v1.2.1 quay.io/operatorhubio/couchbase-enterprise:v1.2.2 quay.io/operatorhubio/couchbase-enterprise:v2.0.0 quay.io/operatorhubio/couchbase-enterprise:v2.0.1 quay.io/operatorhubio/couchbase-enterprise:v2.0.2 quay.io/operatorhubio/couchbase-enterprise:v2.1.0]" error="add prunes bundle couchbase-operator.v1.0.0 (quay.io/operatorhubio/couchbase-enterprise:v1.0.0) from package couchbase-enterprise, channel stable: this may be due to incorrect channel head (couchbase-operator.v2.1.0, skips/replaces [couchbase-operator.v2.0.2])"
Error: add prunes bundle couchbase-operator.v1.0.0 (quay.io/operatorhubio/couchbase-enterprise:v1.0.0) from package couchbase-enterprise, channel stable: this may be due to incorrect channel head (couchbase-operator.v2.1.0, skips/replaces [couchbase-operator.v2.0.2])

https://github.com/k8s-operatorhub/community-operators/runs/5223824016?check_suite_focus=true

[regression] Prometheus Operator fails to start due to RBAC permissions

I've been trying to track down why the Prometheus Operator stopped working recently in our environment, and I've tracked this down to a change in #958 which was filed in #942

The change results in the following output when starting the Prometheus Operator.

level=error ts=2022-04-12T12:49:41.346331692Z caller=klog.go:116 component=k8s_client_runtime func=ErrorDepth msg="pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: Failed to watch *v1.Secret: failed to list *v1.Secret: secrets is forbidden: User \"system:serviceaccount:testing1:prometheus-operator\" cannot list resource \"secrets\" in API group \"\" at the cluster scope"
level=error ts=2022-04-12T12:49:41.747235163Z caller=klog.go:116 component=k8s_client_runtime func=ErrorDepth msg="pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: Failed to watch *v1.Namespace: failed to list *v1.Namespace: namespaces is forbidden: User \"system:serviceaccount:testing1:prometheus-operator\" cannot list resource \"namespaces\" in API group \"\" at the cluster scope"
level=error ts=2022-04-12T12:49:41.887071286Z caller=klog.go:116 component=k8s_client_runtime func=ErrorDepth msg="pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: Failed to watch *v1.Probe: failed to list *v1.Probe: probes.monitoring.coreos.com is forbidden: User \"system:serviceaccount:testing1:prometheus-operator\" cannot list resource \"probes\" in API group \"monitoring.coreos.com\" at the cluster scope"
level=error ts=2022-04-12T12:49:41.918912086Z caller=klog.go:116 component=k8s_client_runtime func=ErrorDepth msg="pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: Failed to watch *v1.PrometheusRule: failed to list *v1.PrometheusRule: prometheusrules.monitoring.coreos.com is forbidden: User \"system:serviceaccount:testing1:prometheus-operator\" cannot list resource \"prometheusrules\" in API group \"monitoring.coreos.com\" at the cluster scope"
level=error ts=2022-04-12T12:49:42.004230409Z caller=klog.go:116 component=k8s_client_runtime func=ErrorDepth msg="pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: Failed to watch *v1.ServiceMonitor: failed to list *v1.ServiceMonitor: servicemonitors.monitoring.coreos.com is forbidden: User \"system:serviceaccount:testing1:prometheus-operator\" cannot list resource \"servicemonitors\" in API group \"monitoring.coreos.com\" at the cluster scope"
level=error ts=2022-04-12T12:49:42.167747675Z caller=klog.go:116 component=k8s_client_runtime func=ErrorDepth msg="pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: Failed to watch *v1.Namespace: failed to list *v1.Namespace: namespaces is forbidden: User \"system:serviceaccount:testing1:prometheus-operator\" cannot list resource \"namespaces\" in API group \"\" at the cluster scope"
...etc

You can reproduce this by running the bundles directly. First create an OperatorGroup to limit this to the local namespace in order to not conflict with existing deployments in other namespaces. I am doing this on OpenShift.

oc new-project testing1

oc create -f - <<EOF
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: operator-sdk-og
  namespace: testing1
spec:
  targetNamespaces:
  - testing1
EOF

operator-sdk run bundle -ntesting1 quay.io/operatorhubio/prometheus:v0.47.0

oc logs -f --selector=k8s-app=prometheus-operator

# <<< RBAC permission errors are seen in STDOUT

oc edit csv prometheusoperator.0.47.0

# <<< edit install.spec.deployments[0].spec.spec.containers.args and add:
# - -namespace=$(NAMESPACES)
# ... back into the containers arguments

# wait for new pod to spin up

oc logs -f --selector=k8s-app=prometheus-operator

# <<< all RBAC permissions are resolved

operator-sdk cleanup prometheus

This is a request to revert the changes in 963cb69 or add the -namespaces=$(NAMESPACES) back in which is the top level configuration option, and then provide a separate ENVVAR to allow overriding for the other instance-namespaces configurations.

Failed to pull kind-registry:5000/test-operator/catalog:v4.10s

Hi, we are getting the following failure with our pr:
redhat-openshift-ecosystem/community-operators-prod#1088

test orange / Deploy o7t (v4.10-db)

fatal: [localhost]: FAILED! => changed=true 
  cmd: podman pull kind-registry:5000/test-operator/catalog:v4.10s
  delta: '0:00:00.121946'
  end: '2022-04-14 05:56:25.753183'
  msg: non-zero return code
  rc: 125
  start: '2022-04-14 05:56:25.631237'
  stderr: |-
    Trying to pull kind-registry:5000/test-operator/catalog:v4.10s...
    Error: initializing source docker://kind-registry:5000/test-operator/catalog:v4.10s: reading manifest v4.10s in kind-registry:5000/test-operator/catalog: manifest unknown: manifest unknown
  stderr_lines: <omitted>
  stdout: ''
  stdout_lines: <omitted>

PLAY RECAP *********************************************************************
localhost                  : ok=211  changed=27   unreachable=0    failed=1    skipped=278  rescued=0    ignored=1   

Error: Process completed with exit code 2.```

[operators/prometheus] operators confilct with clusterRole

Im not sure if this issue is relavent in here, so I will just open this case and hope for help.

I already decribed the issue here, shortly:

when installing few operators, each one of them creates clusterRole with the same name.
in prometheus operator, bot of them tries to modify ClusterRole/monitoring-edit for their own needs.

its not a problem if we install the operator in different namespaces with the same version, but it can cause troubles if we have different versions.

also when using the operator on openshift it conflicts with the operator in openshift-monitoring because of this clusterRole.

would it be possible to call it $(namespace)-monitoring-edit instead of monitoring-edit?

sealed-secrets-operator-helm is deprecated maybe remove from OperatorHub?

The sealed-secrets-operator-helm is deprecated, maybe it should be removed from the OperatorHub?