"helm install —wait" does not wait - workaround

November 11, 2018
Contact Us
Weekly Shorts are topics we discuss in our weekly remote meeting related to recent work we have done with our customers
"helm install —wait" does not wait - workaround

We’re using Helm to deploy services to K8s for several clients we’re supporting. Helm gives you the option to install and upgrade releases in your K8s clusters. As part of this process, the ability to know if the release has ended successfully or not is very important (whether to rollback or not). Helm does this by utilizing an ability to read the deployment status of k8s resources. K8s provides Helm several “metrics” about its health, for example: liveness of the Pod, service’s lack of an endpoint, Pod restart and more. Helm provides the option to add a “wait” and “timeout” flags to install and upgrade commands.

From Helm formal documentation:

https://docs.helm.sh/using_helm/#helpful-options-for-install-upgrade-rollback

Wait: if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment are in a ready state before marking the release as successful. It will wait for as long as — timeout.
Timeout: time in seconds to wait for any individual Kubernetes operation (like Jobs for hooks) (default 300).

Helm is a great tool with many pros BUT unfortunately, we found a major issue with the Wait flag; The Wait flag is used to let Helm server (Tiller) know that we want to wait for the command to finish to understand the status, the issue is the Wait flag supports only K8s resources under the V1 API. So if you use K8s resources in other API namespaces the Wait flag will be usable.

Here you can find the official issue in Helm Github repository:
https://github.com/helm/helm/issues/3173

“wait flag does not wait for deployment pod readiness properly”

And another comment from Helm tests:
https://github.com/helm/chart-testing/blob/4960e30445ead42157850a75245a6c543460ddee/lib/chartlib.sh#L326

“For deployments — wait may not be sufficient because it looks at ‘maxUnavailable’ which is 0 by default”

We use a workaround to solve this issue, for now, the Kubectl command:

kubectl rollout status --watch deployment/SERVICE_NAME --namespace=NAMESPACE

This command uses Kubectl to get the health of the deployment and then we can check the status of the deployment act depending on the result.

"helm install —wait" does not wait - workaround
Ziv Rechnitzer
Senior Operations Architect
With more than 10 years of helping companies solve their operations and delivery problems, he focuses on providing the best experience he can provide. His technical expertise stretches across systems management, managed services and deep understanding of lifecycle management. He tries to spread the DevOps spirit wherever and whenever possible. He is loyal to his customers, reliable and inspires to make an impact on his work. In his spare time, he is a sports fan and enjoys playing boards games, watching movies and tv-shows. He is passionate about executing the most effective solutions that work and focusing on what really makes an impact.