Unable to use Helm charts with required value

Hey all,

I’m pretty new to this whole ecosystem, so I’m probably just missing something. I’m trying to create a Gravity distribution with a helm chart that has a required value:

charts/example/Chart.yaml:

---
apiVersion: v1
name: example
version: 0.0.1

charts/example/templates/example.yaml:

---
image: "{{ .Values.registry }}postgres:9.4.4"
_comment: {{ (required "TEST IS REQUIRED" .Values.test | quote) }}

charts/example/values.yaml:

registry: ""
test: ""

values.yaml:

test: value

But when I run tele build I get TEST IS REQUIRED.
The value doesn’t even seem to matter at this stage, because I think Gravity is just trying to extract the images from K8S resources. Any ideas on how to handle this? Specifically I’m trying to install the Jupyterhub Helm chart (https://jupyterhub.github.io/helm-chart).

Thanks

Hi @ioben

So at the build stage, tele does need to render the helm chart in order to find the images to embed within the installer. It basically does this by including the helm code for helm , and doing the equivalent of helm template without any options to get kubernetes yaml definitions for each object with all the helm templating completed. Tele is then able to scan those objects for image references, that then get embedded within the gravity image used to install the cluster.

To my knowledge, we don’t currently support passing any flags to the rendering process, so the chart itself needs to be setup in a way with default values that will render to the registries that can then be used to download the image. The install hook then needs to override these defaults, so the images get pulled from the local registry instead of the default location.

Hey knisbet,

Yeah that’s what I’m seeing looking at the go code too. I wish it were possible to just manually specify the images that are necessary to pull, instead of trying to do it automatically. Or specify a values.yaml file to use in the prerender step, which could provide those defaults that are necessary. As it stands the current behavior makes it impossible to use many Helm charts. Hopefully a PR rectifying this issue will be accepted.

This is somewhat possible to do, by defining an empty pod yaml object. It doesn’t have to be totally correct, just enough that the object parsed is able to read the file as a pod object. This will cause the build process to find the image. There is then a hidden flag that should tell the build process to ignore the chart itself: https://github.com/gravitational/gravity/blob/master/tool/tele/cli/register.go#L49-L50

It depends a bit on the approach, the hard part is when working with multiple charts that use a setting different way, which chart should be passed a specific set of values. For something like this, I would recommend reaching out with the planned approach with us, so our engineering team can review. This makes it much more likely that the PR will be accepted.