Adding ability to specify an existing secret for use with the message…

[barrymars]

… broker instead of manualling setting credentials in values file

[CLAassistant]

All committers have signed the CLA.

[gionn]

Hello @barrymars and thanks for raising this PR.

We are aware that those charts lacks a proper support of kubernetes secrets as a common standard way to provide sensitive values and we have this kind of improvements on our roadmap (OPSEXP-1651)

The proper approach should be to have a kubernetes secret template populated with the values we currently have (messageBroker.user and messageBroker.password) OR provide a kubernetes secret name like you did.

In this way every template would always reference a kubernetes secret, either managed by the chart itself or an externally managed like you need.

With this requisites in mind, I think we can't yet accept the PR as it is now but I am open to listen for others opinion on that (cc @alxgomz)

[barrymars]

@gionn ok, I can look at expanding my changes to include that, but will take a bit longer

had hoped to add a little bit of functionality without completely rewriting how secrets are handled :)

[barrymars]

ok, so didn't take as long as i thought

haven't had a chance to test this yet, but was this more what you were thinking @gionn ?

[gionn]

haven't had a chance to test this yet, but was this more what you were thinking @gionn ?

indeed it was! I made a quick review and looks fine, now we should proceed to get a green build.

[gionn]

I've pushed two more commits, now I have everything green on a local deployment, now the plan is:

• [x] green CI
• [x] another round of review
• [x] testing on our internal pipeline

[barrymars]

@gionn sorry it's taken a while to get back to this....combination of work pressures and PTO

replied and fixed those last few issues you found

[gionn]

no worries, same situation here 😀 I will take a look hopefully later today or start of the next week and then we should be able to merge 🚀