-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chart: Make controller.config
templatable.
#11181
Conversation
Welcome @TheRealNoob! |
Hi @TheRealNoob. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
✅ Deploy Preview for kubernetes-ingress-nginx canceled.
|
@TheRealNoob , any chance you can create a issue first and describe the current problem with the chart ?
|
I can create an issue describing the value add of this PR. As for the testing I added a unittest for it. To be honest I felt it was a little unnecessary as it's a simple tpl, but I could go either way. Do you still want me to detail how I did my testing locally? |
@TheRealNoob thank you for the contribution, really helps For a normal user reader, the difference between a template for the config and a manually contructed typed content in the values file (indents and all etc), is elaborate with a issue describing what is not possible without a template or what becomes better with a template. We may have to add explaining/docs text the values file for improved experience. So I asked. Please dont feel I insisted. Also wait for other comments as others may also opine that this is enough to move forward. Thank you |
/retitle Chart: Make |
controller.config
through tplcontroller.config
templatable.
/kind feature |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some suggestions. In general I'm not sure if this changes brings more risks than it improves the way users can customize Ingress NGINX to their needs.
You in your case seem to request this change because you're deploying Ingress NGINX in many different namespaces, maybe even as a sub chart.
We should take care not to implement logic that should be handled by users' CI instead, especially if it could weaken type safety like this proposal.
I considered that this might be interpreted as a security risk but dismissed it after realizing that this would only be possible if someone added something to the values file and re-deployed. The act of deploying would require the same level of permissions as editing the object directly, so it's not a security risk from a nefarious actor point of view. The only thing that leaves is the possibility that an administrator intends to deploy one thing, but mistakenly deploys another enabled by this change. Ultimately I concluded that it's a low risk that they'd use double brackets without knowing their special meaning in Helm.
Sorry I don't quote follow your train of thought here, perhaps you could elaborate?
I also considered this but also dismissed this concern since it's already going through the |
Co-authored-by: Marco Ebert <[email protected]>
Co-authored-by: Marco Ebert <[email protected]>
Co-authored-by: Marco Ebert <[email protected]>
The risks I am talking of are mainly about maintaining the chart and supporting users. Some changes might make that harder as they are making the behavior of the chart unpredictable while users are still expecting us to support them in case they are having issues with using what we deliver. So in the end we always consider if a change is really required by more than just one user and still easy to understand and maintain in the future. |
Anyways, I'll give that PR another look by tomorrow (hopefully) and LGTM it asap. |
/label tide/merge-method-squash |
/assign |
/ok-to-test |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Gacko, TheRealNoob The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What this PR does / why we need it:
Allows templating of
controller.config
Types of changes
Which issue/s this PR fixes
How Has This Been Tested?
Checklist: