-
Spike
-
Resolution: Won't Do
-
Blocker
-
None
-
Logging 6.0.0
-
None
-
False
-
-
False
-
NEW
-
NEW
-
-
-
Log Collection - Sprint 258
The problem
Logging 6.0 assumes that the Cluster Obeservability Operator (COO) will install the logging view console plugin. This is the long-term approach we intend for console plugins.
COO will still be tech-preview when logging 6.0 is released, so customers will need to install a new tech-preview component in order to continue to see logs in the console.
Possible solutions
- Provide some form of wording to state that the logging view plugin provided by the COO is GA and supported, even though the COO overall is not. The COO is just a new installation path for an existing GA component.
- Declare the 0.4.0 COO to be GA. It is essentially a re-packaging of existing GA components. The packaging is new but not the functionality.
- Provide documented temporary workarounds that don't depend on the COO by having users directly create/update the console plugin. Note this will expose details of the plugin to users, and allow user mis-configuration and support noise.
Non-solutions:
- Put console reconciliation logic back into logging 6.0. The CLO resources no longer have the information needed to configure the plugin. The CL is retired and the CLF is deliberately decoupled from the loki storage operator.
- Ship the plugin as part of the console. This is part of what the COO is supposed to do for the conosle. Does not make sense to move the implemented COO logic to another home to solve a timing problem.