hashicorp / terraform-provider-helm

Terraform Helm provider

Helm Provider for Terraform

• Documentation
• Mailing list
• #terraform-providers in Kubernetes Slack (Sign up here)

This is the Helm provider for Terraform.

This provider allows you to install and manage Helm Charts in your Kubernetes cluster using Terraform.

Contents

• Requirements
• Getting Started
• Contributing to the provider

Requirements

• Terraform v0.12.x
• Go v1.18.x (to build the provider plugin)

Getting Started

This is a small example of how to install the nginx ingress controller chart. Please read the documentation for more information.

provider "helm" {
  kubernetes {
    config_path = "~/.kube/config"
  }
}

resource "helm_release" "nginx_ingress" {
  name       = "nginx-ingress-controller"

  repository = "https://charts.bitnami.com/bitnami"
  chart      = "nginx-ingress-controller"

  set {
    name  = "service.type"
    value = "ClusterIP"
  }
}

Contributing

The Helm Provider for Terraform is the work of many contributors. We appreciate your help!

To contribute, please read the contribution guidelines. You may also report an issue. Once you've filed an issue, it will follow the issue lifecycle.

Also available are some answers to Frequently Asked Questions.

terraform-provider-helm's Issues

Should helm_chart be renamed to helm_release?

According to Helm documentation:

A Chart is a Helm package. It contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. Think of it like the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file.

A Release is an instance of a chart running in a Kubernetes cluster. One chart can often be installed many times into the same cluster. And each time it is installed, a new release is created. Consider a MySQL chart. If you want two databases running in your cluster, you can install that chart twice. Each one will have its own release, which will in turn have its own release name.

Provider doesn't wait for tiller to be deployed with multiple charts

Given config pasted a bit below (two repositories, two charts), this is what I get

$ terraform apply
google_compute_address.sign_off_checker: Refreshing state... (ID: development-sign-off-checker)
google_container_cluster.primary: Refreshing state... (ID: development)
helm_repository.srcd: Creating...
  metadata.#: "" => "<computed>"
  name:       "" => "srcd"
  url:        "" => "https://src-d.github.io/charts/"
helm_repository.stable: Creating...
  metadata.#: "" => "<computed>"
  name:       "" => "stable"
  url:        "" => "https://kubernetes-charts.storage.googleapis.com"
helm_repository.srcd: Creation complete after 0s (ID: srcd)
helm_chart.bblfsh_server: Creating...
  chart:      "" => "bblfsh-server"
  keyring:    "" => "/Users/rporres/.gnupg/pubring.gpg"
  metadata.#: "" => "<computed>"
  name:       "" => "bblfsh-server"
  namespace:  "" => "default"
  repository: "" => "srcd"
  timeout:    "" => "300"
  version:    "" => "0.1.0"
helm_repository.stable: Creation complete after 0s (ID: stable)
helm_chart.kube_lego: Creating...
  chart:                "" => "kube-lego"
  keyring:              "" => "/Users/rporres/.gnupg/pubring.gpg"
  metadata.#:           "" => "<computed>"
  name:                 "" => "kube-lego"
  namespace:            "" => "default"
  repository:           "" => "stable"
  set.#:                "" => "2"
  set.4096366971.name:  "" => "config.LEGO_EMAIL"
  set.4096366971.value: "" => "[email protected]"
  set.670316139.name:   "" => "config.LEGO_URL"
  set.670316139.value:  "" => "https://acme-v01.api.letsencrypt.org/directory"
  timeout:              "" => "300"
  version:              "" => "0.1.11"
Error applying plan:

2 error(s) occurred:

* helm_chart.kube_lego: 1 error(s) occurred:

* helm_chart.kube_lego: error creating tunnel: "could not find a ready tiller pod"
* helm_chart.bblfsh_server: 1 error(s) occurred:

* helm_chart.bblfsh_server: repo srcd not found

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

A second time reveals an inconsitent state I can only fix by manually removing srcd repo definition from terraform.tfstate file

$ terraform apply
google_compute_address.sign_off_checker: Refreshing state... (ID: development-sign-off-checker)
google_container_cluster.primary: Refreshing state... (ID: development)
helm_repository.srcd: Refreshing state... (ID: srcd)
helm_repository.stable: Refreshing state... (ID: stable)
Error refreshing state: 1 error(s) occurred:

* helm_repository.srcd: 1 error(s) occurred:

* helm_repository.srcd: helm_repository.srcd: repository not found

Terraform Version

Terraform v0.10.3
terraform-provider-helm v0.3.2

Affected Resource(s)

helm_chart resource
helm_repository resource

Terraform Configuration Files

I copy the relevant part. Please let me know if you need more information

provider "helm" {
  kubernetes {
    host                   = "${module.k8s_cluster.endpoint}"
    cluster_ca_certificate = "${module.k8s_cluster.cluster_ca_certificate}"
    client_certificate     = "${module.k8s_cluster.client_certificate}"
    client_key             = "${module.k8s_cluster.client_key}"
  }
}

resource "helm_repository" "srcd" {
  name = "srcd"
  url  = "https://src-d.github.io/charts/"
}

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

resource "helm_chart" "kube_lego" {
  name       = "kube-lego"
  repository = "${helm_repository.stable.metadata.0.name}"
  chart      = "kube-lego"
  version    = "0.1.11"

  set {
    name  = "config.LEGO_URL"
    value = "https://acme-v01.api.letsencrypt.org/directory"
  }

  set {
    name  = "config.LEGO_EMAIL"
    value = "[email protected]"
  }
}

resource "helm_chart" "bblfsh_server" {
  name       = "bblfsh-server"
  repository = "${helm_repository.srcd.metadata.0.name}"
  chart      = "bblfsh-server"
  version    = "0.1.0"
}

Debug Output

https://gist.github.com/rporres/df8dccbf1c51d9cd3751aea19098ecb9

Expected Behavior

Two helm repositories and two helm charts should have been provided

Actual Behavior

No chart was deployed, only one repository seems to have been created properly and system was left in an inconsitent state

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Can we vendor Helm 2.6.0?

Helm 2.6.0 contains a lot of bug fixes that bit me during 2.5.x, one of them is related to cert_file and key_file based client authentication, where the ca_file is not optional: helm/helm@5f96fb8

There's no way to set some values as strings

Currently there's no way to set a value to string "true" or "false" or numbers "12345". Some resources really need these values quoated (eg. some pod annotations).

The snippet bellow

value {
  name = "foo.bar"
  content = "true"
}

yields

foo:
  bar: true

while

value {
  name = "foo.bar"
  content = "\"true\""
}

yields

foo:
  bar: '"true"'

plugin version should be in filename

Terraform provides a mechanism to provide constrains on the version of a provider, but these require the plugin filename to end with the version number in the form _vx.y.z. Currently releases of the plugin do not have this naming convention, and are therefore all seen as version 0.0.0 by Terraform.

See hashicorp/terraform#17051 for more information.

Provider should set up a local environment

The provider should configure $HELM_HOME (like helm init -c does). Without this, on an empty environment, I'm getting an error:

helm_chart.redis: open /home/mstrzele/.helm/repository/repositories.yaml: no such file or directory

Using raw yaml values results in parsing error

We are hitting a bug with the values parameter which is blocking us supply a values.yaml file for a helm chart. The charts we have used are quite large but it appear someone else has already provided a simple re-create in one of the pull request discussions - #15 (comment)

Terraform Version

Terraform v0.11.1

Affected Resource(s)

helm provider

Terraform Configuration Files

resource "helm_release" "kube-prometheus" {
  count = "${var.prometheusDashboard}"
  name      = "kube-prometheus"
  chart     = "coreos/kube-prometheus"
  namespace = "monitoring"
  recreate_pods = "true"
  raw_values = "kube-prometheus-values.yaml"
  depends_on = ["helm_repository.coreos"]
}

values.yaml

hub:
  cookieSecret: "blah"
token:
  proxy: "blah"
singleuser:
  image:
    name: us.gcr.io/blah/blah
    tag: v2.2

Using the same files using the helm cli works fine.

Our yaml is built off a much more complex document - based on https://raw.githubusercontent.com/coreos/prometheus-operator/master/helm/prometheus/values.yaml

Expected Behavior

What should have happened?

Helm chart should deploy.

Actual Behavior

Error: Error applying plan:
``
1 error(s) occurred:

• helm_release.kube-prometheus: 1 error(s) occurred:

• helm_release.kube-prometheus: error unmarshaling JSON: json: cannot unmarshal string into Go value of type map[string]interface {}

### Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
1. `terraform apply`

Tiller image is not installed

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

• Terraform v0.11.3

Affected Resource(s)

Please list the resources as a list, for example:

• helm provider

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

provider "helm" {
  debug                     = "true"
  tiller_image              = "gcr.io/kubernetes-helm/tiller:v2.8.1"
  kubernetes {
      config_path           = "${var.config_file_path}"
  }
}

Debug Output

• n/a

Panic Output

• n/a

Expected Behavior

tiller should have been deployed

Actual Behavior

tiller was not deployed, resulting in

Error: Error applying plan:

1 error(s) occurred:

* helm_chart.helmchart: 1 error(s) occurred:

* helm_chart.helmchart: error installing: Post http://localhost/apis/extensions/v1beta1/namespaces/kube-system/deployments: dial tcp [::1]:80: getsockopt: connection refused

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Important Factoids

• none

References

• none

repository_url does not add repo locally

Terraform Version

Terraform v0.10.3
terraform-provider-helm v0.3.2

Affected Resource(s)

helm_chart

Terraform Configuration Files

resource "helm_chart" "bblfsh_dashboard" {
  name           = "bblfsh-dashboard"
  repository_url = "https://src-d.github.io/charts/"
  chart          = "srcd/bblfsh-dashboard"
  version        = "0.1.0"

  set {
    name  = "service.loadBalancerIP"
    value = "1.2.3.4"
  }
}

Debug Output

* helm_chart.bblfsh_dashboard: no cached repo found. (try 'helm repo update'). open /Users/rporres/.helm/repository/cache/srcd-index.yaml: no such file or directory

If I name the chart without the slash

* helm_chart.bblfsh_dashboard: Non-absolute URLs should be in form of repo_name/path_to_chart, got: bblfsh-dashboard

Expected Behavior

Terraform deploys the chart using helm

Actual Behavior

Terraform does not deploy chart

Workaround

You can manually add the repo. In above case

helm repo add srcd https://src-d.github.io/charts

If it's needed in terraform itself, the above command can be executed via local-exec provisioner

Usage on alpine docker image

Currently it appears that the provider is compiled with required support for glibc, which Alpine doesn't have prepared OOTB in their main image.

Checking in to the linked libraries shows up as:

/go/terraform-provider-helm_linux_amd64 # ldd terraform-provider-helm
	/lib64/ld-linux-x86-64.so.2 (0x7f3e5a379000)
	libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f3e5a379000)
	libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f3e5a379000)

Could we get a compiled release version that would allow us to run the provider inside an Alpine-derived docker container or other containers without glibc?

Race condition on namespace creating when parallel deployments

Hello,

I would like to report an issue when deploying multiple chart release in parallel to the same new created namespace. This issue seems to be a race condition, since it's not happening every time.

count=2 or count=3 seems to have good probability to reproduce the issue.
For some reason, count=10 never reproduced during my tests...

Terraform Version

Terraform v0.11.7
Terraform Helm Provider v0.5.1

Affected Resource(s)

• helm_release

Terraform Configuration Files

In a new folder, create a simple and light testing helm chart:

helm create app
rm app/templates/{deployment.yaml,ingress.yaml}

Add this Terraform code:

resource "helm_release" "apps" {
  count     = 2
  name      = "app${count.index + 1}"
  namespace = "new-namespace"
  chart     = "${path.module}/app"
}

Debug Output

helm_release.apps[1]: Creating...
  chart:            "" => "/tmp/test/app"
  disable_webhooks: "" => "false"
  force_update:     "" => "false"
  keyring:          "" => "/Users/john/.gnupg/pubring.gpg"
  metadata.#:       "" => "<computed>"
  name:             "" => "app2"
  namespace:        "" => "new-namespace"
  recreate_pods:    "" => "false"
  reuse:            "" => "false"
  reuse_values:     "" => "false"
  timeout:          "" => "300"
  verify:           "" => "false"
helm_release.apps[0]: Creating...
  chart:            "" => "/tmp/test/app"
  disable_webhooks: "" => "false"
  force_update:     "" => "false"
  keyring:          "" => "/Users/john/.gnupg/pubring.gpg"
  metadata.#:       "" => "<computed>"
  name:             "" => "app1"
  namespace:        "" => "new-namespace"
  recreate_pods:    "" => "false"
  reuse:            "" => "false"
  reuse_values:     "" => "false"
  timeout:          "" => "300"
  verify:           "" => "false"
helm_release.apps[1]: Creation complete after 2s (ID: app2)

Error: Error applying plan:

1 error(s) occurred:

* helm_release.apps[0]: 1 error(s) occurred:

* helm_release.apps.0: rpc error: code = Unknown desc = release app1 failed: namespaces "new-namespace" already exists

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

Expected Behavior

The two charts should be deployed without namespace creating clash.

Actual Behavior

Randomly, the terraform apply crash.

Steps to Reproduce

terraform init
while true; do
    terraform apply -auto-approve; sleep 2;
    terraform destroy -force; sleep 2;
    kubectl delete ns new-namespace; sleep 5;
done

By watching watch -n 1 'helm list -a | grep app', you will see a failed release deployment sometimes:

app1                    1               Fri May 11 17:18:42 2018        FAILED          app-0.1.0
new-namespace
app2                    1               Fri May 11 17:18:42 2018        PENDING_INSTALL app-0.1.0
new-namespace

Real use-case

I have this race condition in a real context which I reproduced with that simple example.

The real context is 2 nginx ingress controller deployments in the ingress-controllers namespace (without a "loop count", but two separate release definition), one for internal and one for external purpose.

Workaround:

Use two different namespaces for now:

• internal-ingress-controllers
• external-ingress-controllers

Build fails

Hi the build of helm provider fails with:

+ make build
==> Checking that code complies with gofmt requirements...
go install
# github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/helm/pkg/storage/driver
vendor/k8s.io/helm/pkg/storage/driver/cfgmaps.go:74: cannot use "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".GetOptions literal (type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".GetOptions) as type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".GetOptions in argument to cfgmaps.impl.Get
vendor/k8s.io/helm/pkg/storage/driver/cfgmaps.go:100: cannot use opts (type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ListOptions) as type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ListOptions in argument to cfgmaps.impl.List
vendor/k8s.io/helm/pkg/storage/driver/cfgmaps.go:136: cannot use opts (type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ListOptions) as type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ListOptions in argument to cfgmaps.impl.List
vendor/k8s.io/helm/pkg/storage/driver/cfgmaps.go:221: cannot use "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".DeleteOptions literal (type *"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".DeleteOptions) as type *"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".DeleteOptions in argument to cfgmaps.impl.Delete
vendor/k8s.io/helm/pkg/storage/driver/cfgmaps.go:264: cannot use "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta literal (type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta) as type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta in field value
# github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/helm/pkg/kube
vendor/k8s.io/helm/pkg/kube/client.go:69: cannot use config (type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/client-go/tools/clientcmd".ClientConfig) as type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/client-go/tools/clientcmd".ClientConfig in argument to "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/pkg/kubectl/cmd/util".NewFactory:
	"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/client-go/tools/clientcmd".ClientConfig does not implement "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/client-go/tools/clientcmd".ClientConfig (wrong type for ClientConfig method)
		have ClientConfig() (*"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/client-go/rest".Config, error)
		want ClientConfig() (*"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/client-go/rest".Config, error)
vendor/k8s.io/helm/pkg/kube/client.go:132: cannot use unstructured.UnstructuredJSONScheme (type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Codec) as type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Decoder in argument to "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/pkg/kubectl/resource".NewBuilder:
	"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Codec does not implement "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Decoder (wrong type for Decode method)
		have Decode([]byte, *"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime/schema".GroupVersionKind, "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Object) ("github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Object, *"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime/schema".GroupVersionKind, error)
		want Decode([]byte, *"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime/schema".GroupVersionKind, "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Object) ("github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Object, *"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime/schema".GroupVersionKind, error)
vendor/k8s.io/helm/pkg/kube/client.go:174: cannot use info.Object (type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Object) as type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Object in append:
	"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Object does not implement "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Object (wrong type for GetObjectKind method)
		have GetObjectKind() "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime/schema".ObjectKind
		want GetObjectKind() "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime/schema".ObjectKind
vendor/k8s.io/helm/pkg/kube/client.go:192: cannot use o (type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Object) as type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Object in argument to p.PrintObj:
	"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Object does not implement "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Object (wrong type for GetObjectKind method)
		have GetObjectKind() "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime/schema".ObjectKind
		want GetObjectKind() "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime/schema".ObjectKind
vendor/k8s.io/helm/pkg/kube/client.go:257: cannot use originalInfo.Object (type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Object) as type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Object in argument to updateResource:
	"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Object does not implement "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Object (wrong type for GetObjectKind method)
		have GetObjectKind() "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime/schema".ObjectKind
		want GetObjectKind() "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime/schema".ObjectKind
vendor/k8s.io/helm/pkg/kube/client.go:384: cannot use mapping.GroupVersionKind (type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime/schema".GroupVersionKind) as type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime/schema".GroupVersionKind in argument to "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/pkg/api".Scheme.New
vendor/k8s.io/helm/pkg/kube/client.go:399: cannot use target.Mapping (type *"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/api/meta".RESTMapping) as type *"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/api/meta".RESTMapping in argument to createPatch
vendor/k8s.io/helm/pkg/kube/client.go:399: cannot use target.Object (type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Object) as type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Object in argument to createPatch:
	"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Object does not implement "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Object (wrong type for GetObjectKind method)
		have GetObjectKind() "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime/schema".ObjectKind
		want GetObjectKind() "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime/schema".ObjectKind
vendor/k8s.io/helm/pkg/kube/client.go:416: cannot use patchType (type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/types".PatchType) as type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/types".PatchType in argument to helper.Patch
vendor/k8s.io/helm/pkg/kube/client.go:450: cannot use target.Object (type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Object) as type "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Object in argument to c.AsVersionedObject:
	"github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime".Object does not implement "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime".Object (wrong type for GetObjectKind method)
		have GetObjectKind() "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/runtime/schema".ObjectKind
		want GetObjectKind() "github.com/terraform-providers/terraform-provider-helm/vendor/k8s.io/apimachinery/pkg/runtime/schema".ObjectKind
vendor/k8s.io/helm/pkg/kube/client.go:450: too many errors
GNUmakefile:8: recipe for target 'build' failed
make: *** [build] Error 2

I'm using docker for building the provisioner. Here is the dockerfile as well:

FROM golang:1.8 as builder
RUN set -ex \
    && wget \
        https://github.com/Masterminds/glide/releases/download/v0.12.3/glide-v0.12.3-linux-amd64.tar.gz -O- \
        | tar -zx -C /usr/local/bin --strip-components 1 linux-amd64/glide
RUN set -ex \
    && mkdir -p $GOPATH/src/github.com/terraform-providers \
    && cd $GOPATH/src/github.com/terraform-providers \
    && git clone https://github.com/mcuadros/terraform-provider-helm.git \
    && cd $GOPATH/src/github.com/terraform-providers/terraform-provider-helm \
    && glide --home /root/.glide install \
    && make build

Provide a way to deploy the ServiceAccount and ClusterRoleBinding for Tiller on provider setup

Tiller needs a ServiceAccount and ClusterRoleBinding to run.
The provider currently only allows to specify an existing ServiceAccount, but does not allow to create it.
Creating this ServiceAccount and ClusterRoleBinding is currently a pain in the Terraform ecosystem.

Also, how to orchestrate, that the serviceaccount and CRB need to be created before the helm provider is being loaded?

This is why it would be great if the helm provider could create it automatically, maybe based on a yaml file provided.

Outputs..

Hiya,

Just wondering how we can get outputs from charts for use with other terraform modules?

Say we deploy the influxdb helm chart - what would be the right syntax to use to get an output variable - like the IP address?

Allow Tiller to be installed using a service account

For clusters with RBAC enabled, we need the ability to set the appropriate serviceaccount for tiller:

User "system:serviceaccount:kube-system:default" cannot list configmaps in the namespace "kube-system". (get configmaps)

Support for charts in local directory

Background

We use a bunch of local helm charts, currently located in a directory structure in our Git repository.

When starting to adopt Terraform and installing our helm releases using terraform-provider-helm, we discovered that this structure of local charts is not supported.

Even though https://godoc.org/k8s.io/helm/pkg/chartutil#Load supports both directory and file, it seems that terraform-provider-helm requires a tar.gz representation of the chart. This requires us to zip each chart directory before installing any helm release, which seems unecessary.

Feature request

Could terraform-provider-helm also support local directories without requiring them in tar.gz form?

Better description for force_update & recreate_pods

The documentation states:

force_update - (Optional) Force resource update through delete/recreate if needed.
recreate_pods - (Optional) On update performs pods restart for the resource if applicable.

I don't know what either or both of in combination mean. I would expect all pods to be recreated if anything changes. What does force_update do that recreate_pods doesn't?

Random release not found errors

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Terraform v0.10.4

Affected Resource(s)

Please list the resources as a list, for example:

• helm_chart

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

resource "kubernetes_namespace" "metrics" {
    metadata {
        name = "metrics"
    }
}

resource "helm_chart" "prometheus" {
    name       = "prometheus"
    namespace  = "${kubernetes_namespace.metrics.metadata.0.name}"
    chart      = "prometheus"
    repository = "stable"
    version    = "4.5.0"

    set {
        name  = "rbac.create"
        value = true
    }
}

Happens with several different configurations as well

Debug Output

Running terraform for a day with TF_LOG=TRACE and simply can't reproduce the error. Then later this day I forgot to put the option before the command, and it happened again. That's when I decided to open this issue.

Panic Output

None

Expected Behavior

Terraform should just work

Actual Behavior

Terraform fails with helm_chart.prometheus: release not found. While the release is definitely there.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply or terraform plan

Important Factoids

Running Helm 2.6.1 with the same Tiller version.

TLS config for provider is broken

I have installed Tiller onto my cluster with TLS enabled and can confirm that it works using Helm CLI (helm install --tls) without a problem. I couldn't get it to work with terraform-provider-helm, however.

You can read more about setting up TLS for Helm/Tiller here: https://github.com/kubernetes/helm/blob/master/docs/tiller_ssl.md

Version

Terraform v0.11.4
Helm/Tiller is at v2.7.2
terraform-provider-helm is at v0.5.0

Affected Resource(s)

All resources for provider "helm" {}

Terraform Configuration Files

provider "helm" {
  namespace  = "kube-system"
  enable_tls = true
  insecure   = false
  debug      = true

  ca_certificate     = "${file("${var.secrets_dir}/ca.cert.pem")}"
  client_certificate = "${file("${var.secrets_dir}/helm.cert.pem")}"
  client_key         = "${file("${var.secrets_dir}/helm.key.pem")}"
}

Expected Behavior

A chart is successfully installed just like when using Helm CLI.

Actual Behavior

Error: Error applying plan:

1 error(s) occurred:

* helm_release.release: 1 error(s) occurred:

* helm_release.release: context deadline exceeded

Tiller gives this outut:

2018/03/21 09:01:30 grpc: Server.Serve failed to complete security handshake from "127.0.0.1:47944": tls: first record does not look like a TLS handshake
2018/03/21 09:02:12 grpc: Server.Serve failed to complete security handshake from "127.0.0.1:48150": remote error: tls: bad certificate

I also tried removing ca_certificate, client_certificate, and client_key config from the provider in the hopes that the default TLS values ($HELM_HOME/*.pem) will kick in, but I got this output:

1 error(s) occurred:

* helm_release.release: 1 error(s) occurred:

* helm_release.release: rpc error: code = Unavailable desc = transport is closing

Helm provider tries to connect to not yet existing k8s cluster on terraform plan

Given below config

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

Error running plan: 1 error(s) occurred:

* provider.helm: error installing: Post http://localhost/apis/extensions/v1beta1/namespaces/kube-system/deployments: dial tcp [::1]:80: getsockopt: connection refused

Terraform Version

Terraform v0.10.3

Affected Resource(s)

helm provider

Terraform Configuration Files

provider "google" {
  credentials = ""
  project     = "${var.project}"
  region      = "{$var.zone}"
}

resource "google_container_cluster" "primary" {
  name               = "development"
  zone               = "${var.zone}"
  initial_node_count = "1"
  node_version = "1.7.4"
  cluster_ipv4_cidr = "10.12.0.0/14"

  node_config {
    oauth_scopes = [
      "https://www.googleapis.com/auth/compute",
      "https://www.googleapis.com/auth/devstorage.read_only",
      "https://www.googleapis.com/auth/logging.write",
      "https://www.googleapis.com/auth/monitoring",
    ]

    machine_type = "n1-standard-2"
    image_type = "COS"
    disk_size_gb = 100
  }
}

provider "helm" {
  kubernetes {
    host                   = "https://${google_container_cluster.primary.endpoint}"
    cluster_ca_certificate = "${base64decode(google_container_cluster.primary.master_auth.0.cluster_ca_certificate)}"
    client_certificate     = "${base64decode(google_container_cluster.primary.master_auth.0.client_certificate)}"
    client_key             = "${base64decode(google_container_cluster.primary.master_auth.0.client_key)}"
  }
}

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

Debug Output

https://gist.github.com/rporres/5c038ec35e995b062daf92c8291e1eb6

Expected Behavior

Terraform should have been able to create plan without trying to connect to the cluster

Actual Behavior

Apparently it tries to connect to localhost since google_container_cluster.primary.endpoint it is not yet computed

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform plan with given config

concurency issues with multiple chart resources

resource "helm_chart" "core-nginx-ingress" {
  namespace   = "nginx-ingress"
  name        = "core-ingress"
  chart       = "stable/nginx-ingress"
  keyring     = "/dev/null"

  value {
    name    = "controller.service.type"
    content = "LoadBalancer"
  }
}

resource "helm_chart" "kube-lego" {
  namespace   = "nginx-ingress"
  name        = "kube-lego"
  chart       = "stable/kube-lego"
  keyring     = "/dev/null"

  value {
    name    = "image.repository"
    content = "jetstack/kube-lego"
  }
  value {
    name    = "image.tag"
    content = "0.1.5"
  }
  value {
    name    = "config.LEGO_EMAIL"
    content = "[email protected]"
  }
  value {
    name    = "config.LEGO_URL"
    content = "https://acme-staging.api.letsencrypt.org/directory"
  }
}

When applying with -parallelism=10 one of the charts randomly gets wrongfully detected as not found. When running with -parallelism=1 everything works correctly.

New resource shouldn't be required when a chart is updated

-/+ helm_chart.fluent_bit (new resource required)
      id:         "fluent-bit" => <computed> (forces new resource)
      chart:      "http://mstrzele-charts.s3-website-eu-west-1.amazonaws.com/fluent-bit-0.1.0.tgz" => "http://mstrzele-charts.s3-website-eu-west-1.amazonaws.com/fluent-bit-0.1.1.tgz" (forces new resource)

As you can see, I've changed the chart version only. IMHO it shouldn't cause a recreation of the whole release.

I cannot terraform a previously existing release

I want to be able to run terraform apply and have a previously existing helm release be managed by Terraform, rather then Terraform throwing an error saying that the release already exists.

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

terraform-chart-b $ terraform -v
Terraform v0.11.5

• provider.helm (unversioned)

Affected Resource(s)

Please list the resources as a list, for example:

• module.release_a.helm_release.ops_a
• helm_release.ops_b

Terraform Configuration Files

I created two terraform modules, one called terraform-chart-a and one called terraform-chart-b.

Each module contained a chart and a tf state file to install that chart.

The charts were created simply by calling helm create, as in helm create a and helm create b.

The files in terraform-chart-a:

terraform-chart-a $ tree
.
├── charts
│   └── a
│       ├── Chart.yaml
│       ├── charts
│       ├── templates
│       │   ├── NOTES.txt
│       │   ├── _helpers.tpl
│       │   ├── deployment.yaml
│       │   ├── ingress.yaml
│       │   └── service.yaml
│       └── values.yaml
└── main.tf

terraform-chart-a/main.tf:

resource "helm_release" "ops_a" {
    name = "x"
    chart = "${path.module}/charts/a"
}

The files in terraform-chart-b:

terraform-chart-b $ tree
.
├── charts
│   └── b
│       ├── Chart.yaml
│       ├── charts
│       ├── templates
│       │   ├── NOTES.txt
│       │   ├── _helpers.tpl
│       │   ├── deployment.yaml
│       │   ├── ingress.yaml
│       │   └── service.yaml
│       └── values.yaml
├── main.tf
├── terraform.tfstate
├── terraform.tfstate.backup
└── terraform.tfstate.d
    └── jenkins

6 directories, 10 files

terraform-chart-b/main.tf:

module "release_a" {
    source = "git::ssh://<redacted>/terraform-chart-a.git?ref=master"
}

resource "helm_release" "ops_b" {
    name = "b"
    chart = "${path.module}/charts/b"
    depends_on = ["module.release_a"]
}

Debug Output

https://gist.github.com/djhaskin987-at-sling/b3190dd59a219363f45fdfc16c2979f9

Steps to Reproduce

The following steps provide a way to simulate a situation where there are pre-existing releases in helm and I am trying to write a terraform module to manage them.

1. Go into terraform-chart-b repository.
2. Run terraform apply.
3. Delete the terraform state files.

Now, we have an environment where there are previously-existing releases which terraform knows nothing about within Tiller/Helm.

Now, I want to be able to do this:

1. Go into terraform-chart-b repository.
2. Run terraform apply.

Expected Behavior

• Have the terraform state files get updated to reflect that there's a release which already exists.
• Have the terraform apply be a no-op; it doesn't re-install since there is already a release present.

Actual Behavior

See the debug output. Basically, helm says "I tried to create those releases, but they already exist". Terraform throws an error; see the debug output in the gist above.

Important Factoids

Running in minikube on the latest version of master for the provider and Terraform 0.11.5 .

Remarks

This functionality can be implemented either by the plugin supporting terraform import, or it would be cool if there were some way to tell the plugin to run helm upgrade --install instead of helm install on a create, so that if a previous release already existed, terraform would "swallow" it instead of erroring.

helm_chart repository_url does not update existing repository

If I configure my helm chart using repository_url to download the chart, new versions need the cache file to be updated manually (via helm update) or it will fail to provision the new version

Terraform Version

Terraform v0.10.3
terraform-provider-helm v0.3.2

Affected Resource(s)

helm_chart

Terraform Configuration Files

resource "helm_chart" "drone" {
  name           = "drone"
  repository_url = "https://src-d.github.io/charts/"
  chart          = "srcd/drone"
  version        = "0.1.2"
}

Output

terraform apply
(...)
module.drone_server.helm_chart.drone: Creating...
  chart:                "" => "srcd/drone"
  keyring:              "" => "/Users/rporres/.gnupg/pubring.gpg"
  metadata.#:           "" => "<computed>"
  name:                 "" => "drone"
  namespace:            "" => "default"
  repository_url:       "" => "https://src-d.github.io/charts/"
  version:              "" => "0.1.2"
1 error(s) occurred:

* module.drone_server.helm_chart.drone: 1 error(s) occurred:

* helm_chart.drone: chart "drone" matching 0.1.2 not found in srcd index. (try 'helm repo update'). No chart version found for drone-0.1.2

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

Expected Behavior

provider being able to update existing repository

Actual Behavior

It prompted the user for manual update

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply
   with a chart version
2. terraform apply
   with a new version

Provider fails after failed chart deployment

The provider fails after a chart fails. Here is a sample .tf file.

resource "helm_chart" "core-nginx-ingress" {
  namespace   = "nginx-ingress"
  name        = "core-ingress"
  chart       = "stable/nginx-ingress"
  value {
      name    = "controller.podAnnotations.\"prometheus\\.io/scrape\""
      content = "true"
  }
}

Now if you try applying it, first time helm fails with

* helm_chart.core-nginx-ingress: 1 error(s) occurred:

* helm_chart.core-nginx-ingress: rpc error: code = Unknown desc = release core-ingress failed: Deployment in version "v1beta1" cannot be handled as a Deployment: [pos 364]: json: expect char '"' but got char 't'

A helm ls --all core-ingress yields:

NAME        	REVISION	UPDATED                 	STATUS	CHART              	NAMESPACE
core-ingress	1       	Mon Aug  7 17:54:34 2017	FAILED	nginx-ingress-0.7.0	nginx-ingress

Running terraform apply a second time, tries to create a new helm release, which obviously fails because it is already created:

* helm_chart.core-nginx-ingress: 1 error(s) occurred:

* helm_chart.core-nginx-ingress: rpc error: code = Unknown desc = a release named core-ingress already exists.
Run: helm ls --all core-ingress; to check the status of the release
Or run: helm del --purge core-ingress; to delete it

Is this provider still mantained ?

I really like the idea of maintaining the helm chart state with terraform, but seems the development of this provider is somewhat halted (no new commits and stale PR).

Is that the case?

No in-cluster authentication support?

We deploy stuff with Buildkite agents that run in Kubernetes pods, therefore serviceaccount authetication is used.

I had a look through terraform-provider-helm code here and it looked like in-cluster auth is not supported.

If you don't already have this somewhere on a roadmap, I'll get to work on a PR. Thanks for creating and sharing this provider!

Related: should the Kube API endpoint default to https://kubernetes ?

can't create cluster and helm install in same configuration

It seems I can't write a single configuration which creates a GKE cluster and then performs a helm install to the new cluster. When I try, terraform plan fails trying to connect to a non-existent cluster referenced in .kube/config or localhost:

Error running plan: 1 error(s) occurred:

* provider.helm: error creating tunnel: "Get https://104.197.58.127/api/v1/namespaces/kube-system/pods?labelSelector=app%3Dhelm%2Cname%3Dtiller: dial tcp 104.197.58.127:443: i/o timeout"

Is it possible to prevent this checking when applying the configuration, or is that a limitation of how terraform compiles the configuration?

provider.helm: "kubernetes": this field cannot be set

When trying to run the plugin I get this error:

1 error(s) occurred:

* provider.helm: "kubernetes": this field cannot be set

The provider is configured as follows:

provider "helm" {
  kubernetes {
    host                    = "${google_container_cluster.core.endpoint}"
    username                = "${google_container_cluster.core.master_auth.0.username}"
    password                = "${google_container_cluster.core.master_auth.0.password}"
    client_certificate      = "${base64decode(google_container_cluster.core.master_auth.0.client_certificate)}"
    client_key              = "${base64decode(google_container_cluster.core.master_auth.0.client_key)}"
    cluster_ca_certificate  = "${base64decode(google_container_cluster.core.master_auth.0.cluster_ca_certificate)}"
  }
}

config_path: no such file or directory

Seeing this with 0.2.0 release, and I can confirm that the path does exist

Error running plan: 1 error(s) occurred:

* provider.helm: stat ~/.kube/admin.conf: no such file or directory

file ~/.kube/assets/config/test/us-west-1/blue/admin.conf
/Users/user/.kube/admin.conf: ASCII text, with very long lines

Build is failing

Building from HEAD:

make build
==> Checking that code complies with gofmt requirements...
go install
# github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/config
vendor/github.com/hashicorp/terraform/config/testing.go:9: t.Helper undefined (type *testing.T has no field or method Helper)
make: *** [build] Error 2

config_path not being used

I am trying to specify an alternative path to the kubeconfig:

provider "helm" {
  kubernetes {
    config_path = "~/path/to/config"
  }
}

but I am seeing this:

Error running plan: 1 error(s) occurred:

* provider.helm: error creating tunnel: "Get http://localhost:8080/api/v1/namespaces/kube-system/pods?labelSelector=app%3Dhelm%2Cname%3Dtiller: dial tcp [::1]:8080: getsockopt: connection refused"

Terraform Version

Terraform v0.9.11

Affected Resource(s)

• provider

Add support for --devel flag

Currently the helm plugin only installs the chart if the version is 0.3.0. In development settings is usual to have also the branch / build name appended i.e. 0.3.0-489.develop.

helm_release {
   ...
   devel = "true"
   ...
}

allow specifying raw values.yaml

The current approach works well for simple values.yaml overrides, but it gets pretty ugly when you need to pass complex yaml. By allowing to specify a custom values.yaml as string these complex cases can be templated.

Also I would suggest renaming the curent value option with set to be more inline with helm cli. set would get priority over values.

Here is an example for grafana deployment with ingress using the proposed changes:

data "template_file" "grafana_values" {
  template = <<EOF
server:
  ingress:
    enabled: true
    annotations:
      kubernetes.io/ingress.class: 'nginx'
      kubernetes.io/tls-acme: 'true'
    hosts:
      - grafana.example.com
    tls:
      - secretName: grafana-server-tls
        hosts:
          - grafana.example.com
EOF
}

resource "helm_chart" "grafana" {
  name        = "grafana"
  chart       = "stable/grafana"
  values      = "${data.template_file.grafana_values.rendered}"
  set {
    name    = "server.image"
    content = "grafana/grafana:4.4.3"
  }
}

I wil try comming up with a PR.

Ref different-values.yaml within a chart

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)}"
    ]
}

boolean literals don't work w/ helm_release

It appears that literal hci/json boolean values do not work. Eg.,:

resource "helm_release" "redis" {
  name      = "redis"
  chart     = "stable/redis"

  set {
    name = "persistence.enabled"
    value = false
  }
}

Where as quoting the boolean as a string, works. Eg.

  set {
    name = "persistence.enabled"
    value = "false"
  }

It would be fantastic if the provider did the boolean->string conversion or issued a warning that boolean literals are ignored.

helm_release resource doesn't support additional fields on deployment readinessProbe

When trying to install version 1.1.1 of the stable/grafana chart, I get errors related to the extra fields on the readiness probe check.

          readinessProbe:
            httpGet:
              path: /api/health
              port: 3000
            initialDelaySeconds: 60
            timeoutSeconds: 30
            failureThreshold: 10
            periodSeconds: 10

Terraform Version

Terraform v0.11.3
+ provider.helm (unversioned)
+ provider.kubernetes v1.1.0

Affected Resource(s)

• helm_release

Terraform Configuration Files

provider "helm" {
  namespace       = "kube-system"
  service_account = "tiller"
  kubernetes {
    config_path = "~/.kube/config"
  }
}

provider "kubernetes" {
}

resource "kubernetes_namespace" "metrics" {
  metadata {
    name = "metrics"
  }
}

resource "kubernetes_namespace" "logging" {
  metadata {
    name = "logging"
  }
}

resource "helm_release" "prometheus" {
  name       = "prometheus"
  namespace  = "${kubernetes_namespace.metrics.metadata.0.name}"
  chart      = "prometheus"
  repository = "stable"
  version    = "4.5.0"

  set {
    name  = "rbac.create"
    value = "true"
  }
}

resource "helm_release" "grafana" {
  name       = "grafana"
  namespace  = "${kubernetes_namespace.logging.metadata.0.name}"
  chart      = "grafana"
  repository = "stable"
  version    = "1.1.1"
}

Debug Output

https://gist.github.com/gabe-sorensen/7a3e05bd9649bdb34521a92d8920b5d8

Expected Behavior

Terraform creates the resources defined in the chart

Actual Behavior

Terraform displays an error during validation of the data contained in the chart

Steps to Reproduce

1. kubectl create serviceaccount --namespace kube-system tiller
2. kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
3. helm init --upgrade --service-account tiller
4. terraform apply

Important Factoids

Running in minikube

Unknown Authority error when using statically defined credentials

I am seeing this error:

helm_chart.api: error installing: Post https://35.192.46.211/apis/extensions/v1beta1/namespaces/kube-system/deployments: x509: certificate signed by unknown authority

This is my configuration:

provider "helm" {
    kubernetes {
        host     = "${module.kubernetes-cluster.host}"
        username = "${module.kubernetes-cluster.username}"
        password = "${module.kubernetes-cluster.password}"

        client_certificate     = "${base64decode(module.kubernetes-cluster.client_certificate)}"
        client_key             = "${base64decode(module.kubernetes-cluster.client_key)}"
        cluster_ca_certificate = "${module.kubernetes-cluster.cluster_certificate_file}"
    }
}

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

What am I missing @mcuadros ?

Submit the provider to the Terraform Registry

Could you publish this provider to the Terraform Registry (registry.terraform.io)? This will help a lot dealing with the provider with latest versions of Terraform.

Wait for all resources before declaring successful completion

When I deploy to production I usually use helm install <myrelease> --wait --timeout <reasonable timeout for deployment>.
This provider does not provide those options as of yet.
I think that providing those options will improve UX.

Deleted releases

If a release is provisioned with Terraform via this provider and then manually deleted with the command

helm delete <name>

then running terraform apply does not recreate the release. This is because Helm tracks releases even after they've been deleted. The provider will update the release metadata, running

terraform state show helm_release.<name>

will show that metadata.0.status is now DELETED. I would have expected the provider to attempt to rollback or recreate the release.

A work around is to purge the release from helm before applying:

helm delete <name> --purge
terraform apply

Thanks.

Escaping periods in release set names

I've a fleet of services that will all need ingress annotations. For example this an attempt to get traefik-dashboard to use traefik:

set {
  name = "dashboard.ingress.annotations.kubernetes.io/ingress.class"
  value = "traefik"
}

This results in:

apiVersion: v1
items:
- apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    annotations:
      kubernetes: map[io/ingress:map[class:traefik]]

This problem isn't unique to terraform-helm-provider. The helm command line client provides a --set-string option to handle similar.

New Release?

Any chance of a new release rather than having to setup a build env?

terraform refresh is removing namespaces from the cluster / terraform plan is not updating values

Hello,

I'm using terraform v0.11.2 with helm provider 0.3.2.

I have 4 namespaces in my cluster, all created with the helm provider.

$ helm list
NAME            REVISION        UPDATED                         STATUS          CHART                   NAMESPACE  
dev-01          1               Thu Jan 11 08:42:29 2018        DEPLOYED           assembly-dev-1.3.0   dev-01     
kube-system     1               Thu Jan 11 08:41:34 2018        DEPLOYED        system-0.13.0           kube-system
lt-01           1               Thu Jan 11 09:14:27 2018        DEPLOYED           assembly-dev-1.4.0   lt-01      
telemetry       1               Thu Jan 11 08:42:29 2018        DEPLOYED        telemetry-1.14.0        telemetry  
dev-02          1               Thu Jan 11 09:14:27 2018        DEPLOYED           assembly-dev-1.4.0   dev-02     

I can find those 4 namespaces in the tfstate as expected.

When I'm running terraform refresh, the first time it is manipulating all the namespaces:

$ terraform refresh -var-file=../terraform.tfvars -var-file=clusters/dev/cluster.tfvars 2>&1 | more
Acquiring state lock. This may take a few moments...
google_compute_subnetwork.default: Refreshing state... (ID: us-east1/us-east1-pc-dev)
data.google_client_config.current: Refreshing state...
data.template_file.gcloud_credentials: Refreshing state...
google_container_cluster.k8s: Refreshing state... (ID: dev)
null_resource.delete-default-node-pool: Refreshing state... (ID: 3019439159205543985)
google_container_node_pool.k8s: Refreshing state... (ID: us-east1-b/dev/default)
helm_repository.k8s: Refreshing state... (ID: k8s)
helm_chart.kube-system: Refreshing state... (ID: kube-system)
kubernetes_service_account.tiller: Refreshing state... (ID: kube-system/tiller)
null_resource.label-cluster-instances: Refreshing state... (ID: 274257626344228804)
null_resource.helm: Refreshing state... (ID: 1209291922586130472)
helm_chart.k8s[3]: Refreshing state... (ID: dev-01)
helm_chart.k8s[1]: Refreshing state... (ID: telemetry)
helm_chart.k8s[2]: Refreshing state... (ID: dev-02)
helm_chart.k8s[0]: Refreshing state... (ID: lt-01)
Releasing state lock. This may take a few moments...

But at that point, some namespaces are deleted from the tfstate.

The following terraform refresh is not manipulating all the namespaces anymore.

$ terraform refresh 
data.google_client_config.current: Refreshing state...
google_compute_subnetwork.default: Refreshing state... (ID: us-east1/us-east1-pc-dev)
data.template_file.gcloud_credentials: Refreshing state...
google_container_cluster.k8s: Refreshing state... (ID: dev)
google_container_node_pool.k8s: Refreshing state... (ID: us-east1-b/dev/default)
helm_repository.k8s: Refreshing state... (ID: fleet)
helm_chart.kube-system: Refreshing state... (ID: kube-system)
null_resource.label-cluster-instances: Refreshing state... (ID: 274257626344228804)
kubernetes_service_account.tiller: Refreshing state... (ID: kube-system/tiller)
helm_chart.k8s[2]: Refreshing state... (ID: dev-02)
null_resource.helm: Refreshing state... (ID: 1209291922586130472)

At the same time, values and versions are not forced to the cluster. I found the refresh issue while debugging this second issue, I think they are related somehow.

I see on the Readme that the suggestion version for TF is 0.10.*. Is that a compatibility issue with TF? I can't move back to 0.11.* as we use some features of this version (GCP backend).

Add support for depends_on to provider

I want to set up Tiller with a Service Account.
This requires that the Service Account is being created before Tiller gets installed.
I have a module to install the Service Account and the ClusterRoleBinding.

I need to enforce that the module runs before the provider is being executed.

helm provider should support the depends_on command in order that Terraform can set up a proper dependency graph

How to emulate depends_on for modules: https://medium.com/@bonya/terraform-adding-depends-on-to-your-custom-modules-453754a8043e

Proposal: Checksum local charts

Currently the provider doesn't recognize changes in the chart if it's referenced from the local file system, even if you change the version in Chart.yaml file.

A possible solution could be to checksum the canonical contents of a chart and store the sum in the Terraform state. But this would imply checksum all the charts on each refresh in order to check if it was changed. Probably it's not the most efficient way of doing that.

Another approach could be at least tracking a version specified in Chart.yaml and compare it with the one stored in the Terraform state.

Does anyone have more ideas about how changes in a local chart could mark a Terraform resource for an update?

Need to be able to control --kube-context

When running terraform it currently just uses the default helm host and kube-context. There should be a way to override the kube-context with something else. That way you can have two chart resources installed in different namespaces by different user accounts / contexts with different permissions.

Keyring constantly changing

Hi,

Is there a way to force an attribute for all instances of helm_release{}? Every time we run terraform as a different user it wants to change keyring in every helm_release, which is kind of annoying. It's a value we don't set, but it defaults to your homedirectory. Failing that, if it stored it as ~/.gnupg instead of the expanded path, it wouldn't need to change for different users.

Terraform wants to recreate already existing releases

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Terraform v0.10.4

Affected Resource(s)

Please list the resources as a list, for example:

• helm_chart

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

resource "kubernetes_namespace" "logging" {
    metadata {
        name = "logging"
    }
}

resource "helm_chart" "logcollector" {
    name       = "logcollector"
    namespace  = "${kubernetes_namespace.logging.metadata.0.name}"
    chart      = "fluent-bit"
    repository = "${helm_repository.web.name}"
    version    = "0.1.0"
    timeout    = 600

    set {
        name  = "image.fluent_bit.tag"
        value = "0.12.2"
    }

    set {
        name  = "filter.merge"
        value = "On"
    }

    set {
        name  = "backend.type"
        value = "es"
    }

    set {
        name  = "backend.es.host"
        value = "${helm_chart.es.name}-elasticsearch.${kubernetes_namespace.persistence.metadata.0.name}.svc"
    }

    set {
        name  = "resources.limits.memory"
        value = "300Mi"
    }

    set {
        name  = "rbac.create"
        value = true
    }

    # TODO: increase resources
}

Happens with several different configurations as well (note that this is only a partial configuration missing the elasticsearch setup)

Debug Output

Panic Output

None

Expected Behavior

Terraform should just work

Actual Behavior

Terraform wants to recreate already existing releases:

  + module.dev-k8s.helm_chart.logcollector
      id:                   <computed>
      chart:                "fluent-bit"
      keyring:              "/Users/Y9CRPE/.gnupg/pubring.gpg"
      metadata.#:           <computed>
      name:                 "logcollector"
      namespace:            "logging"
      repository:           "web"
      set.#:                "6"
      set.121059550.name:   "rbac.create"
      set.121059550.value:  "1"
      set.2276311802.name:  "filter.merge"
      set.2276311802.value: "On"
      set.3063255997.name:  "image.fluent_bit.tag"
      set.3063255997.value: "0.12.2"
      set.3604222029.name:  "backend.es.host"
      set.3604222029.value: "es-elasticsearch.persistence.svc"
      set.4294762615.name:  "backend.type"
      set.4294762615.value: "es"
      set.983515542.name:   "resources.limits.memory"
      set.983515542.value:  "300Mi"
      timeout:              "600"
      version:              "0.1.0"

Looking at the the log above, it wants to recalculate the id and some metadata immediately after it was already successfully created.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply or terraform plan

Important Factoids

Running Helm 2.6.1 with the same Tiller version.

fatal error: concurrent map writes when deploying multiple resources

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

v0.10.7

Affected Resource(s)

helm_chart

Terraform Configuration Files

provider "helm" {
  kubernetes {
    config_context = "minikube"
  }
}

resource "helm_chart" "kube_lego" {
  name           = "test-kube-lego"
  repository_url = "https://kubernetes-charts.storage.googleapis.com"
  chart          = "stable/kube-lego"
  version        = "0.1.11"

  set {
    name  = "config.LEGO_URL"
    value = "https://acme-staging.api.letsencrypt.org/directory"
  }

  set {
    name  = "config.LEGO_EMAIL"
    value = "[email protected]"
  }
}

resource "helm_chart" "kube_cert_manager" {
  name           = "test-kube-cert-manager"
  repository_url = "https://src-d.github.io/charts/"
  chart          = "srcd/kube-cert-manager"
  version        = "0.1.0"

  set {
    name  = "args.acmeUrl"
    value = "https://acme-staging.api.letsencrypt.org/directory"
  }

  set {
    name  = "args.class"
    value = "default"
  }

  set {
    name  = "args.defaultEmail"
    value = "[email protected]"
  }

  set {
    name  = "google.base64JsonKey"
    value = "eyJhIjoxfQo="
  }

  set {
    name  = "google.project"
    value = "my-project"
  }

  set {
    name  = "installCertificateType"
    value = true
  }
}

Debug Output

Part of the log with the error

2017-12-04T19:53:58.229+0100 [DEBUG] plugin.terraform-provider-helm: fatal error: concurrent map writes
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: goroutine 24 [running]:
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: runtime.throw(0x2d64dcd, 0x15)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/.gimme/versions/go1.9.linux.amd64/src/runtime/panic.go:605 +0x95 fp=0xc4208731e0 sp=0xc4208731c0 pc=0x102a715
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: runtime.mapassign_faststr(0x2ac6660, 0xc420828480, 0x2d59513, 0xc, 0xc420816c30)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/.gimme/versions/go1.9.linux.amd64/src/runtime/hashmap_fast.go:685 +0x4da fp=0xc420873260 sp=0xc4208731e0 pc=0x100cb4a
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema.(*DiffFieldReader).ReadField(0xc420828420, 0xc42049a390, 0x1, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc4208735f8, ...)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/gopath/src/github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema/field_reader_diff.go:80 +0x3a6 fp=0xc4208734c0 sp=0xc420873260 pc=0x16a1976
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema.(*MultiLevelFieldReader).ReadFieldMerge(0xc420544aa0, 0xc42049a390, 0x1, 0x1, 0x2d4ee09, 0x3, 0x0, 0x0, 0x0, 0x0, ...)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/gopath/src/github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema/field_reader_multi.go:45 +0x260 fp=0xc420873608 sp=0xc4208734c0 pc=0x16a5890
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema.(*ResourceData).get(0xc42034c070, 0xc42049a390, 0x1, 0x1, 0xc42049a308, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/gopath/src/github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema/resource_data.go:493 +0x3ed fp=0xc420873740 sp=0xc420873608 pc=0x16b0dad
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema.(*ResourceData).getRaw(0xc42034c070, 0x2d59513, 0xc, 0x2f06e08, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/gopath/src/github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema/resource_data.go:129 +0x95 fp=0xc4208737d8 sp=0xc420873740 pc=0x16ae785
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema.(*ResourceData).GetOk(0xc42034c070, 0x2d59513, 0xc, 0x29fb100, 0xc420815fd0, 0xc4205ac401)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/gopath/src/github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema/resource_data.go:90 +0x5f fp=0xc420873888 sp=0xc4208737d8 pc=0x16ae4bf
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema.(*ResourceData).Get(0xc42034c070, 0x2d59513, 0xc, 0x29fb100, 0xc420815fd0)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/gopath/src/github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema/resource_data.go:69 +0x3f fp=0xc4208738c8 sp=0xc420873888 pc=0x16ae29f
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: github.com/mcuadros/terraform-provider-helm/helm.(*Meta).installTillerIfNeeded(0xc420801c20, 0xc42034c070, 0xc4205ac3f0, 0x46fbf78)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/gopath/src/github.com/mcuadros/terraform-provider-helm/helm/provider.go:315 +0xc1 fp=0xc420873938 sp=0xc4208738c8 pc=0x28d6421
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: github.com/mcuadros/terraform-provider-helm/helm.(*Meta).connect(0xc420801c20, 0x46926c8, 0x0)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/gopath/src/github.com/mcuadros/terraform-provider-helm/helm/provider.go:215 +0x38 fp=0xc420873968 sp=0xc420873938 pc=0x28d5268
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: github.com/mcuadros/terraform-provider-helm/helm.(*Meta).GetHelmClient(0xc420801c20, 0x0, 0xc42078b9d0, 0x1010eb8, 0x70)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/gopath/src/github.com/mcuadros/terraform-provider-helm/helm/provider.go:206 +0x66 fp=0xc420873990 sp=0xc420873968 pc=0x28d51e6
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: github.com/mcuadros/terraform-provider-helm/helm.resourceChartExists(0xc4205ac3f0, 0x2bfb000, 0xc420801c20, 0x24, 0x3ec5340, 0x0)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/gopath/src/github.com/mcuadros/terraform-provider-helm/helm/resource_chart.go:302 +0x44 fp=0xc4208739e0 sp=0xc420873990 pc=0x28da744
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema.(*Resource).Refresh(0xc420801440, 0xc42033c1e0, 0x2bfb000, 0xc420801c20, 0xc4201cfdc8, 0xc42074bf01, 0x80000000018)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/gopath/src/github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema/resource.go:298 +0x3bf fp=0xc420873a88 sp=0xc4208739e0 pc=0x16ad0bf
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema.(*Provider).Refresh(0xc4201bf570, 0xc42033c190, 0xc42033c1e0, 0x46926c8, 0x0, 0x18)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/gopath/src/github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/helper/schema/provider.go:284 +0x9a fp=0xc420873ae0 sp=0xc420873a88 pc=0x16aac0a
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/plugin.(*ResourceProviderServer).Refresh(0xc42045fa00, 0xc42049a280, 0xc42049a350, 0x0, 0x0)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/gopath/src/github.com/mcuadros/terraform-provider-helm/vendor/github.com/hashicorp/terraform/plugin/resource_provider.go:510 +0x4e fp=0xc420873b38 sp=0xc420873ae0 pc=0x1696eee
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: runtime.call64(0xc42074bf20, 0xc42000cdb8, 0xc4206b0510, 0x1800000028)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/.gimme/versions/go1.9.linux.amd64/src/runtime/asm_amd64.s:510 +0x3b fp=0xc420873b88 sp=0xc420873b38 pc=0x1055b2b
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: reflect.Value.call(0xc42076cd20, 0xc42000cdb8, 0x13, 0x2d4f14b, 0x4, 0xc42078bf20, 0x3, 0x3, 0x0, 0x0, ...)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/.gimme/versions/go1.9.linux.amd64/src/reflect/value.go:434 +0x906 fp=0xc420873e60 sp=0xc420873b88 pc=0x10ba516
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: reflect.Value.Call(0xc42076cd20, 0xc42000cdb8, 0x13, 0xc42002cf20, 0x3, 0x3, 0x0, 0x0, 0x0)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/.gimme/versions/go1.9.linux.amd64/src/reflect/value.go:302 +0xa4 fp=0xc420873ec8 sp=0xc420873e60 pc=0x10b9af4
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: net/rpc.(*service).call(0xc4207e1780, 0xc42049d8b0, 0xc4202b6da0, 0xc420447080, 0xc42045fac0, 0x29994a0, 0xc42049a280, 0x16, 0x29994e0, 0xc42049a350, ...)
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/.gimme/versions/go1.9.linux.amd64/src/net/rpc/server.go:381 +0x142 fp=0xc420873f78 sp=0xc420873ec8 pc=0x13e4a52
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: runtime.goexit()
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/.gimme/versions/go1.9.linux.amd64/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420873f80 sp=0xc420873f78 pc=0x10582a1
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm: created by net/rpc.(*Server).ServeCodec
2017-12-04T19:53:58.233+0100 [DEBUG] plugin.terraform-provider-helm:    /home/travis/.gimme/versions/go1.9.linux.amd64/src/net/rpc/server.go:475 +0x36b

Full log is here

Expected Behavior

What should have happened?

No error

Actual Behavior

What actually happened?

Terraform crashed

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

helm_chart.kube_lego: Refreshing state... (ID: test-kube-lego)
helm_chart.kube_cert_manager: Refreshing state... (ID: test-kube-cert-manager)
Error refreshing state: 2 error(s) occurred:

* helm_chart.kube_lego: 1 error(s) occurred:

* helm_chart.kube_lego: helm_chart.kube_lego: unexpected EOF
* helm_chart.kube_cert_manager: 1 error(s) occurred:

* helm_chart.kube_cert_manager: helm_chart.kube_cert_manager: unexpected EOF

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform plan

Workaround

Use parallelism=1