feat: add controller for clusterobservability

[pavolloffay]

Updates #757

• Recording: https://drive.google.com/file/d/1nnLdC7I31ALvigmBQIsksOKe0fxVU-Zs/view?usp=drive_link
• Readme: https://github.com/rhobs/observability-operator/blob/main/docs/clusterobservability.md#deploy-capability-but-dont-deploy-the-operators

This PR adds controller for the ClusterObservability CR. The controller is enabled only on Openshift - when --openshift.enabled=true.

This PR does not add ClusterObservability CR to the bundle so even when the --openshift.enabled=true the implementation is not usable. This is on purpose, the feature will be enabled later on once all items from #757 are resolved.

To deploy the operator with this feature set --openshift.enabled=true and enable the CR

observability-operator/deploy/crds/common/kustomization.yaml

Line 7 in c456486

- observability.openshift.io_uiplugins.yaml

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: pavolloffay
Once this PR has been reviewed and has the lgtm label, please assign alanconway for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jan--f]

Thanks and apologies for the latency in reviewing this. Since iiuc the original design doc is a bit outdated I'll leave some stuff here for now, but perhaps its worth it updating the original doc or setup a new one.

I think we can discuss three facets of this for a bit of structure: sane default configurations for operators, an API that covers multiple signals and the (perhaps optional) installation of additional operators via Subscriptions.
Currently all of these are wrapped up in a single API and while those three features certainly have dependencies, I think a bit more separation would be good to have.

1. We had discussions before that perhaps it would be better for default configs to not just exist in an operator. There are OpenShift flavors that don't bring OLM but rely on other install methods. Can we address this within this proposal?

2. I'm not sure I understand the CommonCapabilitiesSpec type very well. What is the use case to disable capabilities but install them? Wouldn't that just duplicate the functionality the user has already by creating a Subscription CR?
   Perhaps it might be better to ask the user to supply names of subscription CRs to use for a given signal. If the CR exists there is no need to install, otherwise we create the Subscription. If there is no subscription configured for a given signal, the components will not be deployed.
   We can then also require at least on operator subscription to be present to avoid a CR that has no effect.

3. The install flow would be addressed by directly referencing a subscription and creating it if its not found. Additionally identifying an existing subscription would allow us to get some information from it and create more detailed status entries, e.g. about compatibility issues.

[tremes]

Just out of curiosity. What would be the value of these strings?

Is the idea here (in the ClusterObservabilityStatus) to somehow aggregate the status of all the capabilities/components involved? I think it can be quite complicated and with an unclear outcome.

[pavolloffay]

The value is namespace/instance-name (version). I am happy to change it. Do you have any suggestions?

[tremes]

I think this is related to Jan's comment and I am not sure I understand it (and yes I probably missed that in the previous PR so apologies). I thought when a capability is enabled then everything required is installed. It's not the case?

[pavolloffay]

Correct, when a capability is enabled, the operator installs the required operators.

[pavolloffay]

@jan--f I think we should sync on a meeting, since It seems there are some diverged requirements

1. We had discussions before that perhaps it would be better for default configs to not just exist in an operator. There are OpenShift flavors that don't bring OLM but rely on other install methods. Can we address this within this proposal?

I didn't have this goal in mind, nor was it listed in the original document https://docs.google.com/document/d/1VpcxsbGAohBNLa0gaHod_S0mhjGozXOR_I9Ov9DPSyk/edit?tab=t.0. I would prefer to handle non OLM installations separately with defined requirements.

2. I'm not sure I understand the CommonCapabilitiesSpec type very well. What is the use case to disable capabilities but install them? Wouldn't that just duplicate the functionality the user has already by creating a Subscription CR?
   Perhaps it might be better to ask the user to supply names of subscription CRs to use for a given signal. If the CR exists there is no need to install, otherwise we create the Subscription. If there is no subscription configured for a given signal, the components will not be deployed.
   We can then also require at least on operator subscription to be present to avoid a CR that has no effect.

The CommonCapabilitiesSpec is just an internal struct that can be reused across signals.

What is the use case to disable capabilities but install them? Wouldn't that just duplicate the functionality the user has already by creating a Subscription CR?

The use-case for disabled capability with enabled operators install (operators.install: true ) is for a power user. The user in this case install required CRs explicitly but relies on COO to install all required operators (with versions that work together).

Wouldn't that just duplicate the functionality the user has already by creating a Subscription CR?

The goal of this proposal is to simplify the installation, essentially it duplicates everything that a user can create right now with underlying CRs (subscriptions, tempostack, lokistack, uiplugins...).

Perhaps it might be better to ask the user to supply names of subscription CRs to use for a given signal.

Could you please describe the use-case? Do we have a requirement for this? I spent some time thinking about this, and I see it as an edge case (https://github.com/rhobs/observability-operator/blob/main/docs/clusterobservability.md#deploy-capability-but-dont-deploy-the-operators). The main goal of this project is to simplify the installation so users don't have to understand which operators have to be installed and which versions are compatible. Therefore if we don't have requirements I thought we would not (at least initially) support the use-case where users install the operators explicitly, they can do it right now by provisioning everything.

[openshift-ci]

@pavolloffay: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/observability-operator-e2e	702a826	link	true	/test observability-operator-e2e

Full PR test history. Your PR dashboard.

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-sigs/prow repository. I understand the commands that are listed here.

[pavolloffay]

Superseded by #793