Skip to content
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

Consider making charts more dynamic via use of tpl #1760

Open
joaocc opened this issue May 10, 2024 · 3 comments
Open

Consider making charts more dynamic via use of tpl #1760

joaocc opened this issue May 10, 2024 · 3 comments

Comments

@joaocc
Copy link
Contributor

joaocc commented May 10, 2024

Is your feature request related to a problem?

Not a problem but a need and having seen more productivity in other contexts.
Bitnami charts make heavy use of the "tpl" function to allow many/most/all evaluations to be dynamic.
This would also reduce the need to resort to other tools (namely gitops or other ways of evaluating values at deploy time).

Which solution do you suggest?

Convert the new v0.20.x chart (or on a follow up version) to use tpl when evaluating variables in the various templates.
the bitnami.common chart already includes a "common.tplvalues.render" template/function.

Which alternative solutions exist?

Using combinations of gitops, external tools (ansible, bash), or variables in tools like vcluster or other TACOS. All of them increase complexity, even for simple/trivial scenarios.

Additional context

Examples on no particular order:

@rohantmp
Copy link
Contributor

Could you provide specific examples of which values could be automatically determined that aren't already? You'll see a few .tpl files already here: https://github.com/loft-sh/vcluster/tree/main/chart/templates

@joaocc
Copy link
Contributor Author

joaocc commented May 14, 2024

Hi. Didn't explain myself correctly. These values are indeed determined dynamically in the sense that they are conditionally assessed at template generation time. However, all referenced values are values defined statically in values.yaml.

It is not possible, for instance, to define "global.myname: abc" and then refer to abc in the name of the persistence volume (ex: path in NFS) and in the ingress name, without repeating the "abc" string in the different places.
With common.tplvalues.render (or tpl) when evaluating the persistence volume var, and on ingress name, we can reference to global.myname in the values.yaml, making values.yaml more dynamic/DRY.

@joaocc
Copy link
Contributor Author

joaocc commented May 14, 2024

Forgot to add an example to illustrate (different domain, but same concept)

global:
  myname: example.com

service:
  type: ClusterIP
  ports:
    - name: http
      port: 80
      targetPort: http
      URL: {{ printf "http://%s:%d" .Values.global.myname 80 | quote }}
    - name: https
      port: 443
      targetPort: https
      URL: {{ printf "https://%s:%d" .Values.global.myname 443 | quote }}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants