-
Story
-
Resolution: Unresolved
-
Normal
-
None
-
Logging 5.8.z, Logging 5.9.z, Logging 6.0.z, Logging 6.1.z
-
None
-
Future Sustainability
-
5
-
False
-
-
False
-
NEW
-
NEW
-
Bug Fix
-
-
-
3
-
Logging - Sprint 279
Context
If we create a LokiStack with a StorageClassName that doesn't exist in the cluster then the pods of all the StatefulSet components will stay in "pending", this is expected as the cluster will try to provision persistent volumes with a storage class that doesn't exist. However, if we update the StorageClassName to a correct one then the user has to both delete the StatefulSets and only then the PersistentVolumenClaim otherwise he will not be able to get a working stack.
Furthermore, if a customer already has a running LokiStack and updates the StorageClassName to a new valid value then nothing happens as the operator is still not able to preform migrations from one StorageClass to another.
Acceptance Criteria
- New LokiStack resources with an invalid StorageClassName should accept updates and react on those
- Running LokiStack resources with a valid StorageClassName should accept updates to this field and react accordingly, by migrating the data to the new volumes.
- depends on
-
LOG-7390 Loki Operator - Add flexibility to Persistent Volumes
-
- New
-
- links to