-
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
Inconsistent rendering with shared secrets files #251
Comments
I would suspect that #250 fixes this issue. |
@mumoshu @sstarcher Thanks for the quick replies! (I should mention that it's partly because of your attentiveness to this project that I'm using helmfile over tools written in languages I actually understand...grin.) I should have mentioned that I tested with #250 without success. This is the relevant output (which I thought I was receiving because I didn't properly build the binary from the PR):
I just tested with the newest version of helmfile and got the same result. This is promising in that each secrets file was intended to be renamed to a unique filename in the temp directory, but I'm not sure about the "cross-device link" error. Perhaps because my "projects" directory is on a separate partition from my operating system partition (OS is macOS v10.13.6 BTW)? |
Ah, might be the case. @sstarcher Should be |
@bfin |
@bfin Would you mind trying again with the new v0.25.2? |
Progress! Releases now sync with the correct values from secrets files, but the decrypted files remain on disk afterwards. So in my case I'm left with something like...
...where each |
I don't know if it helps, but |
Fixes for the bugs that are introduced by roboll#261, that is values.yaml files specified in `values:` have redundant base path in their prefixes, and remaining .dec files after secrets decryption(roboll#251 (comment))
Fixes for the bugs that are introduced by #261, that is values.yaml files specified in `values:` have redundant base path in their prefixes, and remaining .dec files after secrets decryption(#251 (comment))
@bfin Thanks for testing it out |
@mumoshu I've been stalking your progress on this...grin. Just finished testing: success! Thanks so much for your quick work with these fixes! |
@bfin Thanks a lot for your quick comments and the whole support! Good luck |
@mumoshu thanks for fixing that |
Hi!
I'm seeing inconsistent rendering in my releases when using shared secrets files.
Probably related:
#149 (sync race condition)
#167 (cleaning up shared secrets files)
#250 (PR addressing #167)
Given a helmfile like the following, chart templates in my releases are missing values from some of the secrets.
Furthermore, within a single
helmfile sync
(orhelmfile diff
) command, some releases will receive the secret values and others will not, and either all chart templates in a release receive the secret values or all of them do not receive them. I wish I knew more about go so I could troubleshoot it myself, but it looks like an issue with decryption parallelism. Here is some (sanitized) sample output from several runs ofhelmfile diff
for the above helmfile. Note the inconsistent rendering and multiple attempts to decrypt the same files.Another run...
Another run...
Perhaps an alternative would be to use
sops
directly instead of thehelm secrets
plugin? This would allow you to specify randomized output filenames (helm secrets
only outputssecrets.yaml.dec
) and have the added benefit of freeing users to be able to use other filenames (instead ofsecrets.yaml
), not that that is nearly as important as consistent template rendering!I should note that when I sync the above helmfile – but with the secrets already decrypted and passed in as values files instead of secrets files – all templates in all releases receive the correct values.
Thanks for your help!
The text was updated successfully, but these errors were encountered: