question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

charts: stop using release name in chart templates

See original GitHub issue

One annoying thing about helm charts is the fact that values files can not be templated. For our purpose this would be useful when referring to a k8s resource in the values which is itself defined in another chart template (like a secret). We currently include the release name in the names of our generated resources (except for things like jupyterhub or postgres where this is not the case). This makes the resource names unpredictable. This is actually one reason that made @Panaetius explore helm alternatives. With helm 3 respecting k8s namespaces even more, I think it would be smart to remove the release name from all our templates, get predictable resource names and thus free us from any need to provide andreas-renku-some-secret type of values when deploying RenkuLab. The only drawback I see is that this would make it impossible to have multiple RenkuLab deployments in one k8s namespace, but that’s already not really possible now (Jupyterhub), and I also don’t see why anybody would want to do that.

What do others think about this proposition? @rokroskar @pameladelgado @Panaetius

Issue Analytics

  • State:open
  • Created 3 years ago
  • Comments:19 (17 by maintainers)

github_iconTop GitHub Comments

1reaction
ableulercommented, Sep 22, 2020

Hi @kristofmartens and welcome to the Renku project.

If the conclusion will be that release names will not be added (which is against helm recommendations) I will abandon the PR. Please advise on what to do here as there are clearly 2 schools of thought here 😉

Please note that Renku and Jupyterhub are two independent projects. In Renku we heavily rely und Jupyterhub as a dependency, but we are not maintaining Jupyterhub and therefore can’t tell you if your PR will be considered or not.

Now for the actual topic: Although I don’t understand yet why you can’t create a k8s namespace for each project/jupyterhub instance, I totally agree that it’s helm best practice to add the release name to the resource names. And as a “heavy user” I surely wouldn’t mind Jupyterhub going that way.

The main reason why I suggested that our Renku project might go the other way is how charts (like Renku) interface with their chart dependencies (like Jupyterhub). Specifically, I would like to create a secret in the renku chart and provide it to Jupyterhub through the existingSecret value. Since the values files themselves are not templateable, we either need to have a predictable secret name (which does not include the release name), or the user needs to fill in the correct secret name (which includes the release name) through the values file.

0reactions
ableulercommented, Sep 29, 2020

I think I get your idea of a helper that does that mapping, but as far as I understand there is no way to make the templating engine apply a mapping defined at the renku or renku-notebooks level when evaluating this line I think it will just use whatever is written in

notebooks:
  jupyterhub: 
    hub:
      existingSecret: <name-of-the-k8s-resource>
Read more comments on GitHub >

github_iconTop Results From Across the Web

Helm3: Release Names scoped to Charts? #6339 - GitHub
A Release is an instance of a chart running in a Kubernetes cluster. One chart can often be installed many times into the...
Read more >
The Chart Template Developer's Guide - Helm V2
The helm get manifest command takes a release name ( full-coral ) and prints out all of the Kubernetes resources that were uploaded...
Read more >
Helm adds release name to dependent charts - Stack Overflow
This has nothing to do with it being a dependency, only the name you're using to install the release. Compare: helm install some-chart...
Read more >
How to Reduce Helm Chart Boilerplate with Named Templates
Consider a Helm chart template used to create a deployment, ... how you can reduce boilerplate in your Helm charts by using named...
Read more >
Helm to configure and manage Kubernetes charts - IBM
Release.Revision – The revision number. Begins at 1, and increments with each helm upgrade. Chart – The contents of the chart.yaml. Chart.Name. Chart....
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found