search

fmjstudios / helm

🪖 A collection of MIT-licensed Helm Charts
MIT License
4 stars 7 forks source link

[paperless-ngx] make keys for existingSecrets configurable #10

Open MyChaOS87 opened 1 month ago

MyChaOS87 commented 1 month ago

Name and Version

fmjstudios/paperless-ngx 0.2.0

What is the problem this feature will solve?

When using existingSecrets the keys should not be defined only by the consumer, as those are "existing" as the name already suggests.

What is the feature you are proposing to solve the problem?

use default values, but make those overridable via values.yaml

What alternatives have you considered?

No response

FMJdev commented 1 month ago

I will be closing this as of now since it is considered superseded in paperless-ngx chart release 0.2.1. I have detailed my reasoning in #9.

Feel free to open a new one or reopen this one if you still require the feature and we can talk about the type of API you'd need. 🙌🏼

MyChaOS87 commented 3 weeks ago

@FMJdev I do not consider this as solved (but there is no option to reopen), as the uri parameter in the redis secret as well as the username and password keys inside the secret are still fixed. Which basically means I cannot copy over an existing secret from my postgres deployment to be directly used by this chart.

having to have the uri in the secret for redis is anyways a big issue for me now

FMJdev commented 3 weeks ago

@MyChaOS87, I saw your comment on #9 and agree that the current logic might cause problems with Sealed Secrets etc. I'm not happy with the current behavior myself but as you know, I'm sort of forced into it by Paperless itself.

Could you let me know your secret keys? I see how uri is problematic as I've said, but the username and password should really be the only values we need to keep secret and I'm struggling to see how creating a secret with these keys ahead of time would pose a challenge.

Furthermore it ensures the charts follow Kubernetes conventions and APIs with the (forced) use of the built-in kubernetes.io/basic-auth Secret type. This pattern is also used by hugely popular PostgreSQL Operators like Cloudnative-PG which is also what I use and primarily why I chose this pattern for the charts.

Making the keys to configurable requires the introduction of extra values keys and new .tpl logic which I even initially had in the chart for certain values but decided to remove it due to the reasons above and the clutter it brought to an already quite line long values file.

I am not against introducing changes to suit your use case, however I am also looking to sort of enforce Helm Chart and Kubernetes best practices. I am curious to see which keys and functionality you would require so please be through with your request and I'll try to see how I can introduce those features.