Terraform-provider-helm: Ref different-values.yaml within a chart

[stefanthorpe]

Our charts include our values file for our different environments.

How do I reference say chart/helm_vars/prod/values.tf?

resource "helm_repository" "incubator" {
    name = "incubator"
    url  = "https://kubernetes-charts-incubator.storage.googleapis.com"
}

resource "helm_release" "my_cache" {
    name       = "my_cache"
    repository = "${helm_repository.incubator.metadata.0.name}"
    chart      = "redis-cache"
    values = [
       "${file(chart_location/helm_vars/prod/values.tf)}"
    ]
}

[rporres]

values is used to pass raw yaml, the same way as the -f|--values option in the helm command

I'm unsure of that your values.tf contains, but from the file suffix I'd say it is a terraform file which won't work properly. In that case I guess you will have to use set:

set {
  key1 = "${var.tf_variable_for_key1}"
  key2 = "${var.tf_variable_for_key2}"
}

[stefanthorpe]

"${file(chart_location/helm_vars/prod/values.yaml)}"

That was a simple typo. There is nothing wrong with the yaml files I'm using. They're completely tested and working.
The issue is with the path to them, they are inside the helm_repo at helm_repo_root/helm_vars/prod/values.yaml
and
helm_repo_root/helm_vars/prod/values_2.yaml

I've done a git symlink workaround where I link to my local version of the charts but its really messy and flakey.

[stefanthorpe]

The set command is also messy due to the volume of variables

[rporres]

That was a simple typo. There is nothing wrong with the yaml files I'm using. They're completely tested and working.

That .tf suffix was misleading then 😏

I've done a git symlink workaround where I link to my local version of the charts but its really messy and flakey.

Is this related to this provider or is it a more general terraform thing? Taking a look to the code where those values are parsed it just gets the raw yaml strings you've passed and assigns them to a map. So whatever problem you may be experiencing it appears more related to things like absolute/relative paths...

[stefanthorpe]

Yeah I understand what it does with the yaml, this is an issue in a different way but I PR to dela with that.
The issue is dynamic location.
I don't know where or if helm _repo stores the actual repo or how to reference a values file within that repo.
So Think its this provider, if I reference a git repo, does it cache and store it locally? Is there a variable I can reference to get that path?

value = "${helm.repository.my_chart.root_path}/helm_vars/production.values.yaml}"

[rporres]

I think I'm starting to understand your problem, @stefanthorpe 😅

I don't think a Helm chart downloaded locally from a chart repository is the place to keep the values to deploy in production. A Helm chart should not contain any specific configuration, the same way as a Debian package does not contain the specific configuration for your environment(s). That should be part of your config management system.

If you don't want to use set, I would keep the *.values.yaml files in your repository alongside the rest of the terraform values and refer to them using the file function.

There's a helm chart cache under $HOME/.helm/archive but I would not consider touching it to get your values. That's just asking for trouble.

[rporres]

@stefanthorpe is this still an issue or can we close it?

[stefanthorpe]

I still think this is an issue. I understand your point when the charts are public and being shared. However, I don't think separating the values from the application into the config management is the way to go either. As this creates a separation of duties for Devs and Ops.
Have a chartroot.path variable similar to the module.path then we have a lot more flexibility for none default values.
At the moment I've solved the issue by downloading tmp files from the repo. But this is really hacky.

[rporres]

Let's see what @mcuadros has to say, but from my point of view this is not an issue. You will not find custom configuration in the officially curated charts or in debian packages. Application binaries and configuration should be separated so that application is reusable.

[stefanthorpe]

@rporres Yep understand that. However, in packages, we know where the install root typically is. That allows modifications and changes via additional scripts.
The same is true of modules, we can use that as a ref point.
Even beyond my own requirements, the variable chartroot.path has a tonne of benefits

[dkozlov]

I agree with @stefanthorpe. Now we need to maintain copy of values-production.yaml in our github repo and synchronize it after each chart update. @rporres could you please introduce in terraform-provider-helm relative path to values.yaml located inside the helm package?

[legal90]

@dkozlov Just FYI: you can use ${path.module} to build a quasi-relative path to values e.q. :

resource "helm_release" "logging_kibana" {
  name       = "logging-kibana"
  chart      = "kibana"
  repository = "stable"
  namespace  = "logging"
  version    = "1.6.0"

  values = [
    "${file("${path.module}/values/logging-kibana.yaml")}",
  ]
}

[rporres]

Chart is not the place to keep custom values. As also stated by @legal90, there are ways to keep the configuration in the repository where terraform files are stored and allow for relative paths to be specified. Terraform also has tools to go fancy in the way you get your data (e.g. you can use use external data source) but I fail to see how your configuration should be separated from your deployment code. If you need that it's ok, but you should do it outside the provider using the tools terraform gives you.

[rporres]

Closing this. Feel free to reopen if there's something I've missed here.