-
Bug
-
Resolution: Done
-
Normal
-
None
-
None
-
5
-
False
-
None
-
False
-
-
-
GITOPS Sprint 255, GITOPS Service EE Sprint 256, GITOPS Service EE Sprint 257
Description of problem:
At present the operator only tracks workloads as one of 3 statuses (unknown, pending, running). However, we also have a 4th "Failed" state defined. As of now the operator just calls any failed or pending state workload as "pending" even if it is actually in failed state. This can be misleading as someone will expect the workload to come up eventually but it may never do so
Prerequisites (if any, like setup, operators/versions):
affects all versions{}
Steps to Reproduce
- Launch operator
- Create Argo CD instance
- Enable appset controller, and set image as some invalid image
Actual results:
appset controller status is set to "pending" even though underlying deployment is in failed state with image pull errors that will not be fixed automatically
Expected results:
appset controller status should be reflected as "failed" so users are aware that they have to fix it themselves
Reproducibility (Always/Intermittent/Only Once):
always