Support optional manifests

[fgiloux]

The idea behind optional manifests is that the absence of an API on a cluster, where a BundeDeployment is applied to, may not cause the failure of the complete deployment.

Taking ServiceMonitor as an example, an operator provider may want the resource to get created on clusters where Prometheus is installed but not to fail the installation on other clusters.

[github-actions]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.

[joelanford]

I think this might be something we could solve with operator-framework/operator-controller#381, which would allow extension authors to define parameters to be used with their bundles.

Cluster admins could enable/disable pieces of the bundle's manifests using these parameters (e.g. Extension.spec.params.enableServiceMonitor) . If we went with this approach:

• Operator authors would have fine-grained control different groupings of components/configuration.
• Admins can define the values of those parameters to pick and choose supported components/configurations.
• OLM treats the final parameterized manifests as required. If an API is unavailable, a failure will occur, and the admin can revisit their parameter values to resolve the issue.

I worry a bit about individual optional objects. As a trivial example, if ServiceMonitor is not available, then it might not make sense to create the monitored Service either. I think I would prefer an approach where the extension author and the admin can mutually contribute to an OLM-provided API (e.g. bundle parameters/extension values) that can accommodate different cluster configurations but still results in an explicit deterministic set of manifests applied to the cluster.

@fgiloux Do you think that would be a viable solution?

[fgiloux]

@joelanford is operator-controller #384 what you meant? Its title is "Ability to configure permissions an Operator has" and there is no description. I am not seeing how it relates to "Cluster admins could enable/disable pieces of the bundle's manifests using these parameters (e.g. Extension.spec.params.enableServiceMonitor)"

From what I understand from your comment:

Operator authors would have fine-grained control different groupings of components/configuration.

Yes that would be needed

Admins can define the values of those parameters to pick and choose supported components/configurations.

That is OK but not the best UX. Ideally this would get automatically configured depending on an cluster condition, e.g. availability of an API. This is similar to Helm capabilities.

[joelanford]

Oops. That was a typo. I edited my comment to correct the link (operator-framework/operator-controller#381)

Ideally this would get automatically configured depending on an cluster condition

Ah ha! I see. So a feature that accepts both cluster input and administrator input in order to determine the content of the resulting manifests. That sort of API would still allow this kind of problem to be solved:

if ServiceMonitor is not available, then it might not make sense to create the monitored Service either.

But without requiring admins to know which knobs to turn to get a compatible outcome.

[fgiloux]

So a feature that accepts both cluster input and administrator input in order to determine the content of the resulting manifests.

Yes

[github-actions]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.