Goals

• Centralize Logging Visualization under the hood of the Cluster-Observability-Operator (COO)
• Focus the Cluster-Logging-Operator to core capabilities namely log collection, normalization and forwarding only
• Transform development and maintenance of Logging visualization to a rolling stream mode

Non-Goals

• Implement a new-style design logging view plugin
• Revive the deprecated ClusterLogging resource

Motivation

For years the main development strategy in OpenShift Logging followed the approach to break and decouple centralization of all components in the Cluster-Logging-Operator (CLO) into separately development components. The first huge step being done with moving storage into Loki Operator enabled using the storage product in more than product namely Logging and Network Observability. With the re-design of Logging visualization in form of an OpenShift Container Platform (OCP) Console plugin, we put the building block for logging to be part of a single-pane of glass experience for OCP users. However the plugin installation/upgrade procedure remained since inception bound to the CLO lifecycle. What was meant to be a temporary solution results today in four active maintained version of the Logging plugin with an individual set of features provided per OCP version.

Therefore building upon the re-design of observability UI under the hood of COO, we aim to migrate the current plugin installation/upgrade procedures from CLO into COO using the UIPlugin API. This enables a set of flexible options in future:

1. The installation/upgrades of the Logging UIPlugin can be development at a single place for all supported Logging version.
2. Co-hosting the Logging UIPlugin with all the other observability UIPlugin allows developing and feature interaction among them using a single lifecycle instead of coordination across multiple observability product lifecycle.s

Alternatives

The only alternative to the above is to keep the Logging visualization managed by CLO. However the deprecation and removal of the ClusterLogging API renders a mandatory task to develop a dedicated API to configure just the Logging UIPlugin. Inadvertently this approach results in a second UIPlugin API on OCP and in turn confusion for customers and users around similarities/differences about the APIs themselves as well as their lifecycles.

Acceptance Criteria

1. Given the Logging Administrator wants to enable the Logging Visualization in 6.0, when he/she installs the Cluster-Obervability-Operator, then he/she can create a UIPlugin resource that manages the Logging Visualization for LokiStack-based storage only.
2. Given the Logging Administrator has already enabled the Logging Visualiztion in previous 5.x installs, when he/she creates a COO-managed UIPlugin resource for Loggging, then the CLO will remove and disable further reconciliation of the existing ConsolePlugin.

Risk and Assumptions

RISK: The collaboration between COO and CLO in Logging 5.x installations needs to avoid a constant loop of change over the same ConsolePlugin resources.

MITIGATION: The COO ConsolePlugin resource for Logging will introduce a name (e.g. console-logging-plugin) different than the one currently used "logging-view-plugin" by CLO's ConsolePlugin

Documentation Considerations

Based upon the workflow described for Logging 6.0 in this proposal, the documentation requirements for this bit are:

1. Describe the installation of COO as a prerequisite to get Logging Visualization
2. Describe the creation of the UIPlugin resource for Logging Visualization
3. Add notes in previous versions on what happens when Logging Visualization is installed via COO.

Open Questions

N/A.

Additional Notes

1. Logging 6.0 Workflow as in enhancement prospoal: https://github.com/openshift/enhancements/pull/1537
2. Obervability UIPlugin API: https://github.com/rhobs/observability-operator/blob/main/docs/api.md#observabilityopenshiftiov1alpha1