Adding support for extraManifests for the chart

[JunaidChaudry]

Adding an additional feature to support extraManifests, which allows end-users to deploy any additional k8s resources that they may want to manage along with the helm chart deployment.

Some of the really common use-cases include creating a secret (or secretProviderClass) which the users might be passing on to the hub, or a configmap creation which might then be used with extraVolume, or anything else for that matter.

[JunaidChaudry]

@consideRatio Can you please take a look at this feature request as well?

[consideRatio]

I'd say this is out of scope for the helm chart to suppor this feature. If you want to provide extra manifests etc, you may end up also wanting to provide entire helm charts as well.

The pattern I'd recommend to handle this situation is to create a new chart and add extra things to it, then let it depend on the jupyterhub chart, and install that. This is for example what jupyterhub/mybinder.org-deploy does, its a repo with the deployment configuration for https://mybinder.org. It defines a helm chart that depends on the binderhub helm chart and other helm charts.

Another more lightweight pattern would be to simply do kubectl apply -f some-k8s-resource-manifest.yaml once.

[JunaidChaudry]

Yeah for now that's what we are doing.. However, a lot of major open source helm charts (grafana, kube-prometheus-stack, opensearch, argocd, etc) started supporting it. So I figured it might be worth supporting here as well... Totally up to the maintainers though

[ofirshtrull]

I also think this is relevant @consideRatio
in today's world everything should get fully Gitops I manage x cluster prod and dev, to advise that running a single kubectl apply -f is bad practice in today's world

and to have an umbrella chart only for such a small use-case is a big overhead instead of just adding a manifest or two to the main one

please lets add this support like all the major 3rd party charts it will be very helpfull

[JunaidChaudry]

Any updates here @consideRatio

[aBandicoot]

this is a very important feature, and would help us a lot with managing everything (like secrets) in one place with our jupyterhub deployment values

[frittentheke]

Introducing a values variable that could contain any type of other resource is honestly a messy antipattern in the world of Helm charts and templating. If people want to add additional manifests to this (or a) chart, the Helm way would be to create a parent chart and then add this chart as subchart. This then allows to use a single values file (https://helm.sh/docs/chart_template_guide/subcharts_and_globals/), proper schemas and validation for all of the resources.

[ofirshtrull]

Introducing a values variable that could contain any type of other resource is honestly messy antipattern in the world of Helm charts and templating. If people want to add additional manifests to this (or a) chart, the Helm way would be to create a parent chart and then add this chart as subchart. This then allows to use a single values file (https://helm.sh/docs/chart_template_guide/subcharts_and_globals/), proper schemas and validation for all of the resources.

I disagree, this option makes users maintain another chart just to add a secret/ or a promehtusRule
many mainstream charts are starting to use this cool trick to help such users
i.e a few of them

• https://github.com/grafana/helm-charts/blob/main/charts/grafana/templates/extra-manifests.yaml
• https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/templates/extra-manifests.yaml
• https://github.com/traefik/traefik-helm-chart/blob/master/traefik/templates/extra-objects.yaml

this helps keep using the main chart and just add dependent yamls without the mess of wrapper charts and dependencies

[frittentheke]

Let's say there is a middle ground, as in adding something basic like a single secret or some Prometheus rule, where "your" approach is more lightweight yes. Maybe calling it an anti-pattern was a little harsh.

I'd still argue that more extensive additions should rather be their own chart (a parent) that comes with all of the Helm capabilities, instead of just being a variable or dead string payload.