feat: add controller for clusterobservability

[pavolloffay]

Updates #757

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

[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	e1177ba	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.

[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.

[openshift-merge-robot]

PR needs rebase.

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.

[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.

[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?