charts: stop using release name in chart templates
See original GitHub issueOne 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:
- Created 3 years ago
- Comments:19 (17 by maintainers)
Hi @kristofmartens and welcome to the Renku project.
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.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