helmfile removes all decrypted files

[j-zimnowoda]

While working with helmfile, sometimes I am editing (.dec files (decrypted secrets)

The helm-secrets plugin ensures that

if the secrets.yaml.dec file already exists and is newer than secrets.yaml, it will not be overwritten:
what is great feature, because I can easily change secret values and test them.

Unfortunately helmfile removes secrets.yaml.dec after it reads the file, so I loose data that I was working on.
I am wondering if any of you have ever had the same issue and how do you cope with it.

It would be great if helmfile provides a command line flag to indicate that decrypted files are preserved.

[Morriz]

Aha, it must indeed be the removal by helmfile that is causing this. I suggest to not do anything with the files at all and leave that to the user. Why would helmfile assume what a user wants to do with these files? It should not be helmfile's concern.

And if helmfile wants to support the removal of these files, it should be a flag to specifically instruct it to do so...

[philomory]

Just to clarify, I (sort of) disagree with @Morriz when he states that "I suggest not to do anything with the files at all and leave that to the user." In most use cases, Helmfile is the one creating these files, and it should definitely clean them up when it's done with them.

That said, Helmfile should definitely be checking to see if the decrypted files already exist before it does any decrypting, and if they _do_ already exist, it should leave them in place. In other words, Helmfile should only delete files that it was responsible for creating in the first place, the same as helm secrets itself.

[Morriz]

@philomory I second that :)

[Morriz]

@mumoshu can I ask you to take a look here? I think it would save everybody a lot of time waiting for every file to be decrypted with every invocation of helmfile ;) It seems like a simple problem

[mumoshu]

@j-zimnowoda @Morriz Hey! Thanks for all the info and the feedback.

In #1570, I've added helmfile template --skip-cleanup - as the name says, this retains all the temporary values files rendered by helm-secrets-decrypt and helmfile itself.

Please try it with helmfile --debug template --skip-cleanup, so that you can uniformly debug any rendered values files regardless of how it's produced (helmfile or helm-secrets).

Unfortunately it doesn't retain .dec files yet, as that conflicts with the current helmfile's design that doesn't write any temporary files under the current dir- but I may reconsider that later.

[Morriz]

Ah, that is a big step forward. I assume that means the next command will not decrypt the files again. (Since they are found on disk and to be newer.) That would be a huge performance gain for our development workflow.

Let's see when it lands in the next release

[j-zimnowoda]

Hi @mumoshu thanks for feedback and adding a new feature!
I am pretty sure that your PR relates to another issue that I have also created: #1560, not this one.
Could you double check it?

[Morriz]

Unfortunately it doesn't retain .dec files yet, as that conflicts with the current helmfile's design that doesn't write any temporary files under the current dir- but I may reconsider that later.

Hi @mumoshu we are losing sooooo many cycles still on every helmfile command, since it's helmfile that removes files decrypted before by us. (Why is it removing files it is did not create itself?) Iit is really the bottleneck in our pipeline now.

Again, helmfile shouldn't be messing with files it never created in the first place. So this should be fixed imo.

Btw, we can clean up after ourselves ;)

[Morriz]

Hi @mumoshu :)

You closed this with PR #1560 but we still see the decrypted files removed. We really need to keep them as we now have a bigger issue at hand and need to decrypt before unsetting GOOGLE_APPLICATION_CREDENTIALS as it interferes with kubectl access.

Can you re-open this?

[Morriz]

We now can't deploy to google without going to the trouble of merging service account perms ;|