Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Helm Chart without Parallelism will sometimes deploy the service before the deployment which causes it to hang waiting #1671

Closed
Tracked by #2847
mitchellmaler opened this issue Aug 9, 2021 · 6 comments
Assignees
Labels
area/helm kind/bug Some behavior is incorrect or out of spec mro2 Monica's list of 2st tier overlay related issues resolution/fixed This issue was fixed

Comments

@mitchellmaler
Copy link

Steps to reproduce

  1. deploy helm chart in namespace with parallelism disabled (-p -1)
  2. service is deployed before deployment which causes it to hang waiting for pods that wont ever be deployed

Expected: workloads deploy first
Actual: service deployed before workloads

@mitchellmaler mitchellmaler added the kind/bug Some behavior is incorrect or out of spec label Aug 9, 2021
@mikhailshilkov
Copy link
Member

@mitchellmaler Could you share more details about your scenario, which chart you are deploying, and why you disable parallelism?

@mitchellmaler
Copy link
Author

Hi @mikhailshilkov I was deploying the Rancher chart 2.5.9.
I was disabling parallelism to test that each resource can come up one at a time in the right order. We usually only disable it when we replace multiple nodes that way it only hits one at a time.

@mikhailshilkov
Copy link
Member

Thank you for your response. Unfortunately, I expect that chart resources are deployed in a somewhat random order, as there's no obvious way to order them in a general case. How would you define "the right order"? cc @lblackstone

@mitchellmaler
Copy link
Author

After some more thought I checked with the helm library ordering and it does place service before deployment which is what I experienced.

https://github.com/helm/helm/blob/release-3.0/pkg/releaseutil/kind_sorter.go#L27

So the main issue is how Pulumi will automatically wait on a service for pods to come up but if you reduce or disable parallelism you might end up stuck.

My thought would be to add some mechanism to logically check that the deployment is still queued up while waiting on a service and kick back that wait until afterwards. This would be in a low or disabled parallelism situation since in the default mode it would wait while the deployment is being or soon will be created.

@lblackstone
Copy link
Member

We did sort resources with that ordering in the original TypeScript implementation of our Helm support, but it got dropped at some point since Pulumi automatically retries resource creation. I didn't consider the case where parallelism is explicitly limited, so it may make sense to bring back some ordering. The list that @mitchellmaler linked has Pod, Deployment, etc after Service, so that ordering wouldn't fix this specific problem.

Aside from figuring out an ordering to avoid this problem, you could enable the skipAwait option on the chart. That obviously comes with the downside of not checking resource readiness, but could be an option to get you unstuck for now.

@EronWright
Copy link
Contributor

The upcoming Chart v4 resource has improved support for resource ordering, based on cli-utils as described here. This means that you can apply a config.kubernetes.io/depends-on annotation to ensure that the deployment is installed first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/helm kind/bug Some behavior is incorrect or out of spec mro2 Monica's list of 2st tier overlay related issues resolution/fixed This issue was fixed
Projects
None yet
Development

No branches or pull requests

6 participants