-
Bug
-
Resolution: Done-Errata
-
Normal
-
Logging 5.8.0
-
False
-
None
-
False
-
NEW
-
VERIFIED
-
-
Bug Fix
-
-
-
Log Storage - Sprint 236, Log Storage - Sprint 237, Log Storage - Sprint 238
Description of problem:
For some misconfigurations of the LokiStack the Loki Operator emits a "Degraded" condition on the LokiStack to warn the user about it, for example when setting a secret name that does not exist:
apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: lokistack-dev namespace: openshift-logging spec: size: 1x.extra-small storage: schemas: - version: v12 effectiveDate: 2022-06-01 secret: name: does-not-exist type: s3 storageClassName: gp3-csi tenants: mode: openshift-logging
This should result in a "Degraded" condition with a reason MissingObjectStorageSecret and a status of True to show up in the .status.conditions of the LokiStack resource.
While the condition is created correctly at first, the status is immediately reset to False which should not be the case as long as the error persists.
Version-Release number of selected component (if applicable):
Loki Operator 5.8.0
How reproducible:
Steps to Reproduce:
- Create LokiStack with error condition
- Observe contents of .status.conditions field
Actual results:
Status of Degraded condition is reset to False even though error is still in configuration.
Expected results:
Status of Degraded condition only changes to False when the error is removed from the configuration.
Additional info:
- is cloned by
-
LOG-4156 [release-5.7] Degraded condition on LokiStack is reset even when it should persist
- Closed
-
LOG-4158 [release-5.6] Degraded condition on LokiStack is reset even when it should persist
- Closed
- links to
-
RHBA-2023:6139 Logging Subsystem 5.8.0 - Red Hat OpenShift
- mentioned on