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

Hide the internal API kinds listed in operators.operatorframework.io/internal-objects #14

Open
wallrj opened this issue Feb 15, 2022 · 2 comments

Comments

@wallrj
Copy link

wallrj commented Feb 15, 2022

In https://docs.okd.io/4.9/operators/operator_sdk/osdk-generating-csvs.html#osdk-hiding-internal-objects_osdk-generating-csvs

It is common practice for Operators to use custom resource definitions (CRDs) internally to accomplish a task. These objects are not meant for users to manipulate and can be confusing to users of the Operator. For example, a database Operator might have a Replication CRD that is created whenever a user creates a Database object with replication: true.

As an Operator author, you can hide any CRDs in the user interface that are not meant for user manipulation by adding the operators.operatorframework.io/internal-objects annotation to the cluster service version (CSV) of your Operator.

For example, the couchdb operator have added these annotations:

https://github.com/k8s-operatorhub/community-operators/blob/81a8e860d17591a6acb946a581da4c669ca142d0/operators/couchdb-operator/2.2.1/manifests/couchdb-operator.clusterserviceversion.yaml#L84-L89

But the internal kinds "backups" and "buckets" still show up in the operatorhub.io preview page:
image

So it looks like the authors of that operator have resorted to adding their own (Internal) prefix to the names of all those kinds.

They should be hidden by default.

@J0zi
Copy link
Collaborator

J0zi commented Feb 17, 2022

@dmesser what do you think?

@dmesser
Copy link
Contributor

dmesser commented Feb 17, 2022

@J0zi that makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants