Use Existing Secret in litmus-agent values.yaml

[flockoftanks]

This is really bad practice because it forces me to have to put a password in source control. I see that a feature to add an existingSecret was added to the litmus chart, but I don't see any such feature in the litmus-agent where I need it. Is there a workaround, or can this feature be added?

Thanks!

[Jasstkn]

Hi. There is a workaround so you can run helm upgrade --install set LITMUS_PASSWORD=$SECURE_PASS. But I understand your demand to have this feature in the litmus-agent.

Do you want to wire a PR for this?

[flockoftanks]

We don't manually run helm commands. Everything is automated through GitOps for repeatability. I'm working on a simple fix now.

[Jasstkn]

The issue shouldn't be closed as it's not yet resolved.

[flockoftanks]

The issue shouldn't be closed as it's not yet resolved.

My bad I referenced the issue in my personal fork when merging it into my own master branch. Should be good now with this current MR.

I did a dry-run test on my local machine to verify the chart output and it worked as expected. Not sure this is the cleanest solution of all time, but it'll work and seems somewhat consistent with other solutions in these charts.

[sambonbonne]

I have the same issue, I use global.infraConfigName and global.infraSecretName to use a ConfigMap and a Secret I manage myself but installing and upgrading with Helm erase my ConfigMap and my Secret.

The proposal to have an existingSecret boolean and, if possible, an existingConfig boolean, would allow encapsulating the Secret and ConfigMap templates in a {{ if eq .Values.existingSecret }} (and, for the ConfigMap, {{ if eq .Values.existingConfig }}`) to prevent overwriting existing configuration.