Goals

• Simplify the installation of the entire product logging for Red Hat OpenShift via a single entry operator and a single resource.
• Preserve extending the cluster log forwarding resources with further outputs, filters and tuning configuration.
• Preserve low-level tuning the LokiStack based storage.
• Render the need for the ClusterLogging resource obsolete.

Non-Goals

• Provide a high-level custom resource definitions representing aggregates or compositions of existing Logging CRDs, i.e. ClusterLogging, ClusterLogForwarder and LokiStack.
• Replace existing product components or operators with one single unit to configure and operate them, i.e. Cluster Observability Operator
• Replace existing productization and delivery pipelines with one single product pipeline.

Motivation

For many years all observability products for Red Hat OpenShift have been delivering individually each a single/set of operator(s) that/which package(s) custom resources and operands to run an opionated single observability stack on a cluster based on best-in-class cloud native technologies. Each product maintains for good reasons (i.e. level of maturity, feature set, unique selling points and integrations) its independent delivery pipeline (i.e. ART, CPaas) and release cadence. With the emerge of UI plugins in the OpenShift Console the observability program reached the tipping point to provide a single end-to-end user experience.

Considering all the above mentioned we reach the point where the user experience is deteriorating when users wants to install and operate many observability products at a time. The key challenges they face are:

1. Each observability signal requires custom installation/upgrade procedures.
2. Each observability signal UI mandates custom requirements on support OpenShift releases.
3. Common topology constraints (e.g. scheduling on infra nodes, across zones, etc.) need to be configured for each signal individually.
4. Each product support matrix requires individual consultation and attention to plan upgrades.

Besides these challenges our engineering teams face additional challenges in unifying user experience under the hood of the OpenShift Console in coordinating releases and features that span multiple products over multiple releases (e.g. korrel8r).

In summary the observability program requires a single entry operator to install and operate each stack that maintains low-level configuration/extensibility freedom for each product. In return the Observability UI and cross-cutting features can be unified in this one operator to lessen the coordination effort as well as the friction to get a seamless user experience across observability signals.

The following EPIC represents the work backlog to integrate the logging for Red Hat OpenShift product as an additional offering in the Cluster Observability Operator and enable Logging UI and Korrel8r management between metrics and logs.

Alternatives

1. Orchestrate all installation/upgrades procedures for multiple signals in our place in documentation.

Acceptance Criteria

1. Given I installed only the Cluster Observability Operator, then I want to install the entire product logging for Red Hat OpenShift with a single resource named LoggingStack.
2. Given I created the LoggingStack resource defining a particular release channel (e.g. stable-5.8), then I want to upgrade to the next stable release via the same resource.
3. Given I created the LoggingStack resource, I want to get out-of-the box correlation of metrics and logs for infrastructure components.
4. Given I created the LoggingStack resource and installed OpenShift User Workload Monitoring, I want to get out-of-the box correlation of metrics and logs for application workloads.
5. Given I created the LoggingStack resource, I want to get only UI features available for the cluster version hosting the current logging product installation.

Risk and Assumptions

RISK: A major risk in represented in the above diagram is that the installation procedure is a reconcilation of resources maintained by the Operator Lifecycle Manager (OLM) which in particular might:

1. Not be easy to track installation status and success given that installation is represented by multiple resources in a chain (Subscription, InstallPlan, ClusterServiceVersion).
2. The Operator Framework undergo a major shift towards allowing a multi-tenant system that allows multiple operator versions to co-exist (See [1]). This might require a substantial migration effort later on.

RISK: The concentration of all Observability UI view plugins under one operator can possibly slow down releasing the Cluster Observability Operator as often as aspired too because each release needs to support a matrix of products and their support lifecycles, e.g.:

• Cluster Observability Operator Release 1.0 on 4.14 needs to support:
  • 4x Logging releases namely 5.7 (EOL month past 5.9), 5.8 (EOL EUS-alinged 4.12-4.14), 5.9 (EOL month past 6.0) and 5.8 (EOL EUS-aligned 4.14-4.16)
  • Each logging release has individual feature gates on the UI side: https://github.com/openshift/logging-view-plugin?tab=readme-ov-file#compatibility-matrix

Documentation Considerations

TBD.

Open Questions

TBD.

Additional Notes

1. Operator Framework Roadmap: https://docs.google.com/presentation/d/1c-H_UcyeACq314QsK1aWo8qFi_iuZLzIHTJ7xQ-ZcTQ/edit#slide=id.g29c4f44a122_6_0
2. Spike LoggingStack with UI: https://github.com/rhobs/observability-operator/pull/417
3. ObservabilityUIPlugin APIs: https://github.com/rhobs/observability-operator/pull/434
4. Enhancement Proposal: https://github.com/openshift/enhancements/pull/1566