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

Usage of --wait by default #83

Open
consideRatio opened this issue Jun 27, 2020 · 1 comment
Open

Usage of --wait by default #83

consideRatio opened this issue Jun 27, 2020 · 1 comment

Comments

@consideRatio
Copy link
Collaborator

I've come to think --wait is a very bad practice in Helm, and run into some issues right now while developing locally due to it.

A motivation is provided in consideRatio/consideratio.github.io#6, but in general the short version is that usage of --wait where someone choose not to wait the duration will put things into a bad state. Then, the value of --cleanup-on-fail can also be lost.

I think the only place --wait could make sense given its technical weaknesses, is in automation where one is always ready to await the full duration. Even there, it may be questionable though I think.

I'd love to see it removed by default somehow.

@yuvipanda
Copy link
Collaborator

The primary reason for '--wait' is that if it fails, we know the deploy failed. Otherwise you might end up in states - for example, when the hub image is wrong, or it is in crashloopbackoff, etc - where hubploy 'succeeds'.

Cancelling a deploy in the middle of a '--wait' definitely puts things in a weird state - a bug that keep hoping the helm people will fix. Ideally, this would be two commands - one to do the deploy, and one to wait for all resources to be ready. This should work around the issue.

I think if we can remove '--wait' while keeping it so that a hubploy deploy will fail if the deployment fails, I'd really really love that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants