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

Adding support for extraManifests for the chart #3134

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

JunaidChaudry
Copy link
Contributor

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
Copy link
Contributor Author

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

@consideRatio
Copy link
Member

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
Copy link
Contributor Author

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

@JunaidChaudry JunaidChaudry force-pushed the feature/support-extraManifests branch from c7bca4a to cb1ae1d Compare June 7, 2023 13:48
@ofirshtrull
Copy link

ofirshtrull commented Sep 28, 2023

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

@manics manics closed this Dec 6, 2023
@manics manics reopened this Dec 6, 2023
@JunaidChaudry
Copy link
Contributor Author

Any updates here @consideRatio

@aBandicoot
Copy link

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
Copy link

frittentheke commented Aug 15, 2024

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
Copy link

ofirshtrull commented Aug 15, 2024

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

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

@manics manics closed this Aug 15, 2024
@manics manics reopened this Aug 15, 2024
@frittentheke
Copy link

frittentheke commented Aug 15, 2024

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.

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

Successfully merging this pull request may close these issues.

6 participants