-
Notifications
You must be signed in to change notification settings - Fork 564
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
helmfile sync, multiple charts in same namespace results in a race condition #149
Comments
@Stono Thank you for the detailed report. Good catch! This should be fixed. IMHO, this is an upstream issue, because it is helm who is doing a kind of optimistic-locking. It could detect the race by looking to the error cause. If it can't be fixed upstream early, I'd rather like helmfile to retry only once on WDYT? |
I agree I really don't want to limit to a concurrency of 1 in a namespace. We can either retry or we can create the NS ahead of time if it does not exist, but an issue should be opened upstream. |
I shall open it upstream :-) |
I'm facing similar (but not the same) issue: when specifying same secrets file for several charts, it results in race while cleaning up files:
|
@amnk Ah, good catch! It could happen. Would you mind raising another issue for that? |
@mumoshu done. And thanks for prompt replies! |
The upstream issue is already fixed by @Stono's awesome PR, and it has been already released as part of helm v2.10! So, closing this as fixed. Thanks everyone for your supports 🎉 |
Hey,
If you have a helmfile, which:
Then you can run into a race condition where helm will attempt to create that namespace multiple times:
None of these charts contain a
namespace.yaml
, this is purely due to helm creating the namespace as part of thehelm install
.Suggestion
Perhaps helmfile could be smart enough to enforce a concurrency of 1, per namespace, when the namespace doesn't already exist?
The text was updated successfully, but these errors were encountered: