This message was deleted.

Sounds reasonable to me, but I'd defer to @Raz Co's wisdom on the matter

The way it’s written, with the helper functions,I would need to break apart the server and client values. Since it’s taking the registry base and assuming both client and server names.

Hey @Avo Sepp welcome back, What you offer sounds reasonable, do you want me to take a look and try to find another workaround or you prefer the way you offered ?

No, I don’t think a work around is appropriate here. I think there’s some expected behavior with the ability to specify the registry, and with the way we create custom Docker images for different fetchers, that we’re going to have more than 1 possible name for client and server. So that should be broken out into two blocks in the values file and then the

permitio/opal-client

can be put in as a default that I can override.

I agree, that’s the best practice of defining dynamic images templates.

I’ve gone ahead and applied a work around in our CR. I just renamed our client to match. So I’m not in a rush. I’d actually love to tackle some of this Helm chart with you at a later point.

Great, I’ll tackle this in the next days. Have a great day ✌️

Actually, I’d love to have a design meeting to discuss ways we can make the Helm chart a little more friendly to DevSecOps. The mechanism for loading OPAL config risks exposing secrets in Git. I believe we can modify this approach to allow the user to independently define a K8s Secrets Manifest where the config exists. Maybe we can schedule something next week. I’m thrilled to work on this with you.

I love you approach ! We’re actually about to release a major version of OPAL in the next few weeks - v2, so it’ll be an exciting opportunity to refactor this chart. Let me get back to you with more information about this :)