I am trying to build a chart and define parameters with default values. While doing helm install, the user can override certain fields using user defined values.yaml. But I don't want the user to change the certain fields during upgrade.
For Ex:
values.yaml
id: "testId"
name: "testName"
It should throw error when user tries to change the value during helm upgrade.
values.yaml
id: "idChanged"
name: "testName"
Is there a way to do it in helm charts?
You can use values.schema.json file as a reference schema with all the properties to handle this scenario. further info you can read from here
During helm upgrade if certain values have to to be skipped, set the readonly option to true and this would result in error if user tried to update them during helm upgrade
Related
I have a helm chart which creates namespace and bunch of other Kubernetes resources. I want make sure that user will not be able to change the namespace name once created. I was trying to use JSON schema validation but it cannot compare old and new value. What would be right way to do validate if existing value is changed in the helm values for the existing helm release.
I'm using the mongodb helm chart and the mongo-express one. mongodb generates the name depending on my release name, so it is dynamic. The mongodb service name will be something like my-release-mongodb.
mongo-express requires to pass mongodbServer - the location at which the mongodb can be reached. How can I provide this value to mongo-express if it is generated and can change depending on the release name?
Helm doesn't directly have this ability. (See also helm - programmatically override subchart values.yaml.) It has a couple of ways to propagate configured values from a subchart to a parent but not to use computed values, or to send these values to a sibling chart.
In the particular case of Services created by a subchart, I've generally considered the Service name as part of the chart's "API": you know the Service will be named {{ .Release.Name }}-mongodb and you just have to hard-code that in the consuming chart.
If you're launching this under a single "umbrella" chart, this is a little more straightforward. Both parts have the same release name, so you can construct the service name the same way. (Umbrella charts have other limitations – if you have multiple services that each should have an independent MongoDB installation, Helm will only deploy the database once for the whole umbrella chart – but you can still hit this same problem making HTTP calls between microservices.)
If they're totally separate installations, you may need to pick the release name yourself and pass it in as a value.
helm install thedb ./mongodb
helm install theapp ./mongo-express --set serviceName=thedb-mongodb
This also a place where a still higher-level tool like Helmfile or Helmsman can come in handy, since that would let you specify these parameters in a fixed file.
I have followed the Helm Subchart documentation to create a parent chart with a sub-chart.
When I install the parent chart, the sub-chart comes along for the ride. Great!
However, if I try to install another instance of the parent chart with a different name, I get an error saying the sub-chart already exists.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: kind: Service, namespace: my-namespace, name: my-subcharts-service
I had expected the sub-chart to be installed if it did not already exist. And if it did exist I expected everything to be ok. Eg I thought it would work like a package management system eg pip/yum/npm
Is there a way to share a sub chart (or other helm construct) between multiple instances of a parent chart?
I'm creating a Chart for a web application that requires a Postgres database. As I understood dependencies are references to other charts that will be installed along with the one you define, e.g.:
# Chart.yaml
dependencies:
- name: bitnami/postgresql
version: "8.10.5"
repository: "https://charts.bitnami.com/bitnami"
My question is how can you specify the configuration properties (--set, or values.yaml file) needed not only in your application but also for each of the dependencies?
First of all, you should use name: postgresql and not name: bitnami/postgresql because charts are usually not prefixed.
Error: bitnami/postgresql chart not found in repo https://charts.bitnami.com/bitnami
You can override subcharts values putting them under chart name (in your case postgresql) in values.yaml
postgresql:
postgresqlDataDir: /data/postgresql
Or with --set postgresql.postgresqlDataDir=/data/postgresql
More info in Subcharts and globals
You can define your dependency charts in charts.yaml.You can also have conditions when you want your dependencies to be deployed or not.
Your dependecy chart is basically your child chart of the parent.A parent can always override the child chart values.
In your parent values.yaml you can override child values like this
postgresql:
## Create a database user
## Default: postgres
postgresqlUsername: username
## Default: random 10 character string
postgresqlPassword: password#123
postgresqlDatabase: database
You can also specify the override at the time of helm install using set command
I have a helm chart with an optional component. It seems that the preferred way to support optional components is to break them into separate charts and toggle them with tags.
I tried this, but my optional component needs to know a variable from the rest of the chart (the address of a particular service). This causes things to break
Error: render error in "subchart/foo-deployment.yaml":
template: superchart/templates/_helpers.tpl:14:40:
executing "superchart.variable <.Values.variable...>:
can't evaluate field name in type interface {}
I believe you can do this at install time for the chart
helm install --set option1=value1 --name my-release stable/dask
For more info:
https://docs.helm.sh/helm/#helm-install
Issue:
https://github.com/kubernetes/helm/issues/944
PR:
https://github.com/kubernetes/helm/pull/982