[FEATURE]: Enable helm --wait flag
#6053
Assignees
Labels
Comments
eysi09
pushed a commit
that referenced
this issue
Nov 12, 2024
Previously we would use Garden's own resource monitoring to monitor the health of a Helm install/upgrade and fail fast if one of the resources was unhealthy as well as show K8s events and Pod logs. In commit 7a68373 we replaced that with Helm's own `--wait` flag. The reason for that change was because a user reported issues with Garden returning early from the Helm command in the success case (see #6078 and #6053 for more details). The problem with that change is that since we weren't using our own resource monitoring we stopped showing events and logs when Helm installs/upgrades fail. Another problem is that Garden would now wait for the Helm command to complete which in the case of unhealthy resources means Helm will timeout, with a default of 300 seconds. This commit fixes that and we try to go for the best of both worlds: - We always use the `--wait` flag but also monitor resources at the same time - If the resources are healthy we wait for the Helm command to complete (this was the intent with 7a68373) - If we detect unhealthy resources we fail fast (as we did before on the same major version) - We add a flag to overwrite the fail fast behaviour in case a user might prefer that
eysi09
pushed a commit
that referenced
this issue
Nov 12, 2024
Previously we would use Garden's own resource monitoring to monitor the health of a Helm install/upgrade and fail fast if one of the resources was unhealthy as well as show K8s events and Pod logs. In commit 7a68373 we replaced that with Helm's own `--wait` flag. The reason for that change was because a user reported issues with Garden returning early from the Helm command in the success case (see #6078 and #6053 for more details). The problem with that change is that since we weren't using our own resource monitoring we stopped showing events and logs when Helm installs/upgrades fail. Another problem is that Garden would now wait for the Helm command to complete which in the case of unhealthy resources means Helm will timeout, with a default of 300 seconds. This commit fixes that and we try to go for the best of both worlds: - We always use the `--wait` flag but also monitor resources at the same time - If the resources are healthy we wait for the Helm command to complete (this was the intent with 7a68373) - If we detect unhealthy resources we fail fast (as we did before on the same major version) - We add a flag to overwrite the fail fast behaviour in case a user might prefer that
github-merge-queue bot
pushed a commit
that referenced
this issue
Nov 14, 2024
fix(k8s): re-enable showing logs + failing fast on Helm errors Previously we would use Garden's own resource monitoring to monitor the health of a Helm install/upgrade and fail fast if one of the resources was unhealthy as well as show K8s events and Pod logs. In commit 7a68373 we replaced that with Helm's own `--wait` flag. The reason for that change was because a user reported issues with Garden returning early from the Helm command in the success case (see #6078 and #6053 for more details). The problem with that change is that since we weren't using our own resource monitoring we stopped showing events and logs when Helm installs/upgrades fail. Another problem is that Garden would now wait for the Helm command to complete which in the case of unhealthy resources means Helm will timeout, with a default of 300 seconds. This commit fixes that and we try to go for the best of both worlds: - We always use the `--wait` flag but also monitor resources at the same time - If the resources are healthy we wait for the Helm command to complete (this was the intent with 7a68373) - If we detect unhealthy resources we fail fast (as we did before on the same major version) - We add a flag to overwrite the fail fast behaviour in case a user might prefer that Co-authored-by: Eyþór Magnússon <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature Request
Background / Motivation
We use Garden to test our helm charts in CI and we found an error that when deploying with Flux we had a mistake in the order of our hooks that only manifested in this case. We found that if we add the
helm install --waitflag this should mimic that behavior.Its not clear how the Helm deploy action in Garden handles this behavior and I would like to enforce the flag to be used so we can fully test hook ordering.
What should the user be able to do?
Add a
waitoption to the Helm deploy action configuration that controls the usage of the--waitflag when runninghelm install.Suggested Implementation(s)
Self-explanatory.
How important is this feature for you/your team?
🌵 Not having this feature makes using Garden painful
There really isn't a workaround short of me writing a ConfigTemplate reimplenting the Helm deploy action, so we know that our CI is not testing completely, but it doesn't strictly block a workflow so it doesn't make things unusable.
The text was updated successfully, but these errors were encountered: