operator-sdk bundle validate should ignore missing examples for "internal" APIs

[wallrj]

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.

So there is no reason to add examples (alm-examples) for these internal APIs.

operator-sdk bundle validate should only print a "missing example" warning for the APIs which are not listed in the operators.operatorframework.io/internal-objects annotation.

Related to:

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

[jmrodri]

I will take this issue and get more information to find out what that validator does and propose some options here in this issue.

[jchunkins]

This should be the code path for this validation https://github.com/operator-framework/api/blob/master/pkg/validation/internal/csv.go#L78

[camilamacedo86]

If I am not wrong, Scorecard also checks the alm-examples. However, it raises a WARN and is not an ERROR, no matter the check.

In POV: If we decide to move forward with the suggestion over not raising warnings, suggestion to add the alm-examples when the CRD is informed via the annotation operators.operatorframework.io/internal-objects:

• The annotation is valid only for UI / console then, we need to check if it is or not OCP specific first
• We need to address it in Scorecard and Validators checks

Also, the idea is we have a CVSless bundle in the future, and these annotations ought to become properties with names that clarify better what component actually uses it. So, I'd also ask, how much real value do we bring by addressing this RFE? What problem do authors actually face because of the WARNING suggesting to use the alm-examples? How many operators use operators.operatorframework.io/internal-objects and would take advantage of it?

Thinking on the cost vs benefit here, I think we could spend this effort on other features which could bring more value and help the Operator Authors. However, assuming that the annotation is not OCP specific, I'd not have objections if the community would like to address it.

[asmacdo]

This should be filed against api/

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.