-
|
Currently the status of action conditions (Installed, Upgraded, Rolledback, Uninstalled, Tested) persists for as long as the spec (generation) and calculated state (e.g. resolved chart version, values from secret/configmap, out of band helm actions) do. They don't take into account for example resetting:
Do these conditions represent: a. current state of the release (more consistent with how conditions were intended to be used) None of the conditions are used by the controller itself, so it should be a question of human UX. At least |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
What we know from talking to Flux (v1) / Helm Operator users is that they like to be able to see "what happened during a release", and what resulted in the failed state. In the first release we did not have anything in place to push events, so the only place this information could be captured was the conditions field. I do agree that recording the current state of the release is indeed more consistent with how conditions were intended to be used, as long as we broadcast an event with the result of every action that was run. |
Beta Was this translation helpful? Give feedback.
-
|
Resolved here: fluxcd/helm-controller#75 |
Beta Was this translation helpful? Give feedback.
What we know from talking to Flux (v1) / Helm Operator users is that they like to be able to see "what happened during a release", and what resulted in the failed state. In the first release we did not have anything in place to push events, so the only place this information could be captured was the conditions field.
I do agree that recording the current state of the release is indeed more consistent with how conditions were intended to be used, as long as we broadcast an event with the result of every action that was run.