Terraform-provider-helm: Support Helm 3.0

[alexkreidler]

Helm 3.0 is in alpha and is heading towards being released. It would be great to start working on support for 3.0 so we could use it as soon as it comes out.

My main concern is it seems that this terraform plugin directly uses Tiller through RPCs. However, Helm 3.0 is eliminating tiller in favor of a client-side system that then directly uses the Kubernetes API.

It seems like a significant refactor to move from the lower-level code that currently makes up this plugin to the types of simpler API calls to the helm library, which is why it would be good to start soon.

Thanks for a great plugin!

[aaronmell]

3.0 is still in Alpha, Once the first beta drops, it should be worked on. I think working on it now might be painful.

[enummela]

Just want to point out the Helm 3.0 beta was released today. Very much appreciate the efforts keeping this provider up to date. It will be exciting to follow the progress. Thanks!

https://github.com/helm/helm/releases/tag/v3.0.0-beta.1

[aaronmell]

Anyone taking a stab at this? I might spend some time this weekend working on it.

[aaronmell]

@rporres Asking you, since you are the most active contributor to the project. How should we handle the 3.0 work? I think we have should create a long running branch with the v3 work in it until it reaches GA. Should we have new providers/resources for v3, and rename the old resources to v2?

[aaronmell]

I opened https://github.com/helm/helm/issues/6333 and submitted a PR https://github.com/helm/helm/pull/6341 to improve the configuration building in helm v3

[aaronmell]

Thinking about it some more, there is no way to really support both helm 2 and helm 3 in a single version of the provider. I think bumping the major version is the correct answer, and maintaining a v2 branch for some period of time.

[rporres]

@aaronmell I will find time to discuss with @alexsomesan how to organise this and come back to you

[alexsomesan]

Now that Helm 3.0 is tagged as Beta, it meets the theoretical criteria to be considered for support in the provider. We should evaluate whether that comes with any API stability guarantees.

[alexsomesan]

I agree with that we can't support both versions in the same provider version. We would keep maintaining v2 for as long as possible with Helm 2.0 support only and bump major for Helm 3.0 support.

[aaronmell]

Still waiting on My PR to be accepted. Also still waiting on Go Module support to be merged into the helm 3.0 branch.

[OJFord]

I realise it's not as slick implementation-wise, but since we're using terraform anyway couldn't helm template [...] | kubectl apply -f - & kubectl delete -f - be used, as the state is stored in terraform and so not actually needed in tiller/helm3 as well? (And would work for either helm version.)

Rough PoC: https://raw.githubusercontent.com/OJFord/terraform-module-helm3/master/main.tf

[kim0]

Now that helm3 is at beta-3 .. I'm hoping support for that will land soonish. The most annoying part about the "old" provider, is not being able to reuse existing kubernetes providers. Thanks!

[OJFord]

I notice @aaronmell's PR helm/helm#6341 was merged yesterday, thanks! 👍

Do you also have WIP for the provider that uses it? I've not written much Go, but would be happy to help in testing or such.

[aaronmell]

I was waiting for Go Modules to be finished. I ran into a brick wall trying to consume helm as a dependency. Might have some time this weekend to start it.

[aaronmell]

I've got a rough start on the v3 provider at
https://github.com/aaronmell/terraform-provider-helm/tree/dev-v3
Managed to get the data repository resource running. Still needs a lot of work though. I also have a second PR opened with helm to fix a regression in my PR.

Would be nice if we could get a branch for v3 work @rporres @alexsomesan @meyskens so others could hack on it.

[aaronmell]

Made some more progress last night, about 80% done with the release provider. Targeting having that completed by next week some time.

That will leave some cleanup, and documentation.

[aaronmell]

Close to have the tests working for releases. The provider is creating the releases, just in the wrong namespace. The provider doesn't allow you to pass in the namespace, so I opened a PR to correct it. Went ahead and pushed what I have right now in case someone is interested

[aaronmell]

Got the first release test to pass. I pushed the changes into my branch.
Things left to do

1. Get the rest of the tests working
2. Add back the kubeconfig options I initially removed thinking it wouldn't be needed
3. Update the documentation
4. Need to figure out some test related settings.

[kim0]

Awesome! Glad to see progress on this one! Will it be possible to use the standard kubernetes provider with this provider ? i.e. without basically duplicating it inside ?

[aaronmell]

@kim0 Hopefully it will work just like the v2 plugin

[msvechla]

Thanks for the awesome work and time you put in here. Let me know if there is anything where we can support and jump in as well

[aaronmell]

Hoping that this week I can knock out the remaining tests

[ams0]

eagerly waiting for this too, thank you for your work!

[aaronmell]

All but one test is passing now.

[NandoTheessen]

Helm 3.0.0 was released today :+1: https://helm.sh/blog/helm-3-released/

[aaronmell]

I could use some help here

I can't see a way to support using anything but the config file path, which removes existing functionality. Wouldn't mind someone else taking a look at that issue, and seeing if its possible.

Still trying to get TestAccResourceRelease_updateExistingFailed running. If someone wants to take a look at that also, I would appreciate it.

Going to try tomorrow to sync with the latest helm and provider, before doing some integration testing with my own stuff.

[aaronmell]

If you are helping, please comment here, so we don't have multiple people stepping on each other.

[robbert229]

Ok, so I checked out your lovely work @aaronmell, is it your intention to remove support for the kubernetes block as a configuration option? Or is this a temporary wip change?

[aaronmell]

@robbert229 It's was one of the items I asked for help with. After thinking about it last night, I think I know how to add them back. We pass the ConfigFlags stuct to Helm when initializing it. I believe most if not all of those options can be set on ConfigFlags, and the Kubeconfig path, can be left null, and it should work.

[invidian]

I've been actually playing a bit with using helm 3 as a library and I managed to factor out the bits, so I can load the config from the content of the kubeconfig file, maybe you find it useful for supporting kubernetes block in provider's configuration: https://gist.github.com/invidian/032c6fd48fb9d71d8fd47283dcd255f7

[aaronmell]

I got things synced with v3.0.0 and the latest in master.
Started doing integration tests, fixed a bug, and the first chart to install fails in my test environment. Helm 3 installs the same chart fine. There is some issue with the values parser, or how the values are being send to the helm client.

[Stackout]

I started looking at it yesterday morning, didn't have much time to go through it yesterday evening. I'll see if I can contribute later this evening. I'll test my charts on v3 without terraform, then I'll test with terraform and see if I can identify anything.

[msvechla]

I tried your latest branch version and there still seem to be some bugs. My test deployment is created successfully, however the terraform run never finishes, as it is always waiting for a successful release to be created.

So it looks like something is missing for registering the final helm release. I will try to dig into it. This is what I used for testing:

provider "helm" {}

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

resource "helm_release" "nginx-ingress" {
  name       = "nginx"
  repository = "${data.helm_repository.stable.metadata.0.name}"
  chart      = "nginx-ingress"
  version    = "1.25.0"

  set {
    name  = "controller.name"
    value = "helmtest"
  }
}

❯ kubectl get deployments nginx-nginx-ingress-helmtest
NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
nginx-nginx-ingress-helmtest   1/1     1            1           7m21s

❯ helm3 list
NAME    NAMESPACE   REVISION    UPDATED STATUS  CHART   APP VERSION

[msvechla]

After some digging it seems that we should switch the helm driver to secret, as this is the default for helm 3. I cant even see an option to switch this on the helm 3 CLI.

When specifying the helm_driver as secret in the provider section I am now able to see the release with the helm cli.

However terraform still times out, because of

• helm_release.nginx-ingress: timed out waiting for the condition

So something is still wrong when the provider verifies the installation. As the installation is successful via CLI.

[FuNK3Y]

Could it be the same bug: https://github.com/helm/helm/issues/6751 but in branch v3 ? Symptoms are similar

[aaronmell]

After some digging it seems that we should switch the helm driver to secret, as this is the default for helm 3. I cant even see an option to switch this on the helm 3 CLI.

When specifying the helm_driver as secret in the provider section I am now able to see the release with the helm cli.

However terraform still times out, because of

• helm_release.nginx-ingress: timed out waiting for the condition

So something is still wrong when the provider verifies the installation. As the installation is successful via CLI.

@msvechla Pushed a change to swap that to the default

[robbert229]

@aaronmell are you still having some issues with the tests and looking for help on them? Or do you have that handled?

[relu]

I've managed to test locally with minikube using the stable/mariadb chart release example specified in the README and it works just fine (create, update and destroy).

I think the problem @msvechla reported regarding stable/nginx-ingress might be chart specific, I was able to reproduce it through helm cli as well and once I checked the resources i.e. kubectl get all -l app=nginx-ingress, I noticed the controller service was stuck in the pending state:

service/nginx-nginx-ingress-controller        LoadBalancer   10.105.239.184   <pending>     80:31647/TCP,443:32286/TCP   73s

Kudos @aaronmell for the great work!

[relu]

Another update from my side. I went a bit deeper with testing and it seems there might be an issue with passing in values. Here's a snippet from my configuration with the output errors as comments above each resource block:

# Succeeds                                                                                                                                                                                             
resource "helm_release" "example_0" {                                                                                                                                                                 
  name        = "prometheus-operator-0"                                                                                                                                                               
  repository  = data.helm_repository.stable.metadata.0.name                                                                                                                                           
  chart       = "prometheus-operator"                                                                                                                                                                 
  version     = "~> 8.2.0"                                                                                                                                                                            
  max_history = 5                                                                                                                                                                                     
}                                                                                                                                                                                                     

# Error: type mismatch on grafana: map[%!t(string=image):map[%!t(string=tag):%!t(string=6.4.4)]]                                                                                                                                       
resource "helm_release" "example_1" {                                                                                                                                                                 
  name        = "prometheus-operator-1"                                                                                                                                                               
  repository  = data.helm_repository.stable.metadata.0.name                                                                                                                                           
  chart       = "prometheus-operator"                                                                                                                                                                 
  version     = "~> 8.2.0"                                                                                                                                                                            
  max_history = 5                                                                                                                                                                                     

  values = [<<-YAML                           
    grafana:  
      image:          
        tag: 6.4.4   
  YAML              
  ]                           
}                

# Error: type mismatch on grafana: map[]    
resource "helm_release" "example_2" {
  name        = "prometheus-operator-2"
  repository  = data.helm_repository.stable.metadata.0.name
  chart       = "prometheus-operator"
  version     = "~> 8.2.0"
  max_history = 5 

  values = [<<-YAML   
    grafana: {}     
  YAML                                        
  ]           
}                  

# Error: type mismatch on grafana: map[]
resource "helm_release" "example_3" {
  name         = "prometheus-operator-3"
  repository   = data.helm_repository.stable.metadata.0.name
  chart        = "prometheus-operator"
  version      = "~> 8.2.0"         
  max_history  = 5   
  reuse_values = true

  values = [<<-YAML
    grafana: {}    
  YAML                 
  ]                           
}

On a separate note, when I tried running on EKS with a larger values chunk, a configuration that worked just fine with helm v2 failed with the following error:

Error: rpc error: code = Unavailable desc = transport is closing

I suspect this has to do with the new helm values schema validation, however due to lack of experience with these implementations I wasn't quite able to properly track it down, I'm sure some of you folks might be able to figure that out more easily.

Would be glad to help out as much as I can with this.

[invidian]

@relu what about:

  values = [
<<EOF                       
grafana:
  image:
    tag: 6.4.4
EOF
  ]

I removed all whitespace, fixed indentation, used EOF tags and moved it to new line. This is equivalent of following Terraform code, which works properly:

locals {
  test = [
<<EOF
foo:
  bar: baz
EOF
  ]
}

output "foo" {
  value = yamldecode(local.test.0).foo.bar
}

Note: you need TF 0.12.x to run it.

[aaronmell]

@aaronmell are you still having some issues with the tests and looking for help on them? Or do you have that handled?

Any help would be appreciated. My availability to work on the provider from now until the new year is rather limited.

[relu]

@invidian I don't think indented heredoc could be a cause for such an issue considering the fact that the same configuration worked just fine with the helm v2 provider and also considering the errors which suggest problems with schema validation and not with YAML parsing. In any case, I did try your suggestion and ran using unindented heredoc + made absolute sure YAML indentation was correct but to no avail.
I am running on TF 0.12.x of course.

[relu]

I dug into this a bit and it looks like the problem is with yaml unmarshaling going on here and caused by this issue.

The relevant failure is captured here.

In the previous helm v2 version of the provider a different package was used for yaml operations: github.com/ghodss/yaml while now gopkg.in/yaml.v1 is imported.
Note that helm uses this package "sigs.k8s.io/yaml" which seems to have the correct behaviour for map[string]interface{} types (built and tested using that and it works as expected). I will follow-up with a PR to @aaronmell's branch.

[chris-brace]

Thanks for doing all of this work. For institutional reasons i had to upgrade to v3 immediately in order to remove tiller. As a result i've had to remove the sections of terraform that rely on the helm provider :( Let me know if there's something i can do to help test cause i'd really like to bring em back in! I have nginx-ingress / datadog / several proprietary releases running locally and in two real managed EKS clusters that i can play around with if it helps.

[aaronmell]

I dug into this a bit and it looks like the problem is with yaml unmarshaling going on here and caused by this issue.

The relevant failure is captured here.

In the previous helm v2 version of the provider a different package was used for yaml operations: github.com/ghodss/yaml while now gopkg.in/yaml.v1 is imported.
Note that helm uses this package "sigs.k8s.io/yaml" which seems to have the correct behaviour for map[string]interface{} types (built and tested using that and it works as expected). I will follow-up with a PR to @aaronmell's branch.

That fixed the tests as well. Thanks

[aaronmell]

I'm Working on adding back in the kubernetes config from v2.

[relu]

@aaronmell let me know if I can help. I've been actually investigating this a bit as well.

Aside from that, I have a branch where I've implemented helm v3 release importing (it lacks tests though, need to work on that).

[aaronmell]

@relu Changes pushed for that.

[aaronmell]

I've opened the PR to get feedback from the community. I have at least 2 issues, maybe others that need completion before it can be merged, but I think its close enough to get feedback on.

[jakesyl]

I'm testing this on my configuration today and will add any notes here

[rowecharles]

Hi @aaronmell, I'm having issues with k8s config for the helm provider. I'm testing using a GKE cluster with this config (this config works for the kubernetes provider):

provider "helm" {
  kubernetes {
    load_config_file = false

    host                   = google_container_cluster.cluster.endpoint
    token                  = data.google_client_config.current.access_token
    client_certificate     = base64decode(google_container_cluster.cluster.master_auth.0.client_certificate)
    client_key             = base64decode(google_container_cluster.cluster.master_auth.0.client_key)
    cluster_ca_certificate = base64decode(google_container_cluster.cluster.master_auth.0.cluster_ca_certificate)
  }
}

It fails with

Error: invalid configuration: certificate-authority-data and certificate-authority are both specified for gke_ck-gcp-training_europe-west2_fluxing. certificate-authority-data will override.

I assume this is due to the provider not respecting load_config_file = false so loading my kube config file which includes certificate-authority-data.

The only way I can get it to work is have the helm provider empty but this requires kube config is already configured.

Other than this I have no issues install releases.

[aaronmell]

Hi @aaronmell, I'm having issues with k8s config for the helm provider. I'm testing using a GKE cluster with this config (this config works for the kubernetes provider):

provider "helm" {
  kubernetes {
    load_config_file = false

    host                   = google_container_cluster.cluster.endpoint
    token                  = data.google_client_config.current.access_token
    client_certificate     = base64decode(google_container_cluster.cluster.master_auth.0.client_certificate)
    client_key             = base64decode(google_container_cluster.cluster.master_auth.0.client_key)
    cluster_ca_certificate = base64decode(google_container_cluster.cluster.master_auth.0.cluster_ca_certificate)
  }
}

It fails with

Error: invalid configuration: certificate-authority-data and certificate-authority are both specified for gke_ck-gcp-training_europe-west2_fluxing. certificate-authority-data will override.

I assume this is due to the provider not respecting load_config_file = false so loading my kube config file which includes certificate-authority-data.

The only way I can get it to work is have the helm provider empty but this requires kube config is already configured.

Other than this I have no issues install releases.

I tried testing this, and I am unable to reproduce at least with the debugger attached. Can you paste your helm config file? Are you using the latest commit?

Do you have KUBE_LOAD_CONFIG_FILE env set to true?

Also, I think the issue might be with helm, and not the terraform provider. Do you have a default config at ~/.kube/config? Can you try running the provider after renaming that config?

[relu]

@aaronmell I was able to reproduce this by having a kubeconfig file configured in ~/.kube/config, I then set the context kubectl config use-context <some eks cluster>, made sure no environment variables were set and ran terraform plan using the latest build, it fails exactly with the error described by @rowecharles. I'm not able to reproduce this with minikube. Will look into it as well.

[rowecharles]

To add some further detail my kube config is created from gcloud container clusters get-credentials ... and looks like

clusters:
- cluster:
    certificate-authority-data: LS0tLS1C...
    server: https://xx.xx.xx.xx
  name: gke_helm3

This is different from minikube config which uses certificate-authority rather than certificate-authority-data. Might be why @relu can't reproduce with minikube

clusters:
- cluster:
    certificate-authority: /Users/crowe/.minikube/ca.crt
    server: https://192.168.64.7:8443
  name: minikube

If I remove my kube config file it fails with a different error cluster unreachable

[relu]

Got some bad news, this is most certainly not an issue with the provider but rather an issue with the underlying configuration management implemented in the k8s.io/client-go package.

The only workaround I could find was to set the config_path = "/dev/null" or to some empty file (non-existing file will cause an error). This seems to prevent the loading of the kubeconfig file from the standard location. Of course, this can be implemented in the provider but it seems quite hacky to me to be honest. I think some clarification would be needed from the k8s maintainers cause I'm not entirely sure if this behaviour was intended or if it's a bug, I would expect the default kubeconfig to not be loaded if the genericclioptions.ConfigFlags struct's KubeConfig field is set to nil.

[aaronmell]

Got some bad news, this is most certainly not an issue with the provider but rather an issue with the underlying configuration management implemented in the k8s.io/client-go package.

The only workaround I could find was to set the config_path = "/dev/null" or to some empty file (non-existing file will cause an error). This seems to prevent the loading of the kubeconfig file from the standard location. Of course, this can be implemented in the provider but it seems quite hacky to me to be honest. I think some clarification would be needed from the k8s maintainers cause I'm not entirely sure if this behaviour was intended or if it's a bug, I would expect the default kubeconfig to not be loaded if the genericclioptions.ConfigFlags struct's KubeConfig field is set to nil.

You should open a ticket in the k8's project and reference this issue.

I think the hacky workaround is probably our best bet at this point, until it can be fixed upstream.

[relu]

Here's the hack, it involves yet another tempfile, as if I didn't use enough of these already :)
https://github.com/relu/terraform-provider-helm/tree/dev-v3-prevent-loading-local-kubeconfig

[robinsk]

FWIW, our workaround for preventing loading local kubeconfig is as simple as pointing config_path to a non-existent file:

provider "helm" {
  kubernetes {
    load_config_file = false

    host                   = "…"
    client_certificate     = "…"
    client_key             = "…"
    cluster_ca_certificate = "…"

    config_path = "ensure-that-we-never-read-kube-config-from-home-dir"
  }
}

[relu]

FWIW, our workaround for preventing loading local kubeconfig is as simple as pointing config_path to a non-existent file:

provider "helm" {
  kubernetes {
    load_config_file = false

    host                   = "…"
    client_certificate     = "…"
    client_key             = "…"
    cluster_ca_certificate = "…"

    config_path = "ensure-that-we-never-read-kube-config-from-home-dir"
  }
}

That's not possible, considering that config_path is completely ignored if load_config_file is false. Are you sure you are testing with the correct build version? You should build on the dev-v3 branch from https://github.com/terraform-providers/terraform-provider-helm/pull/378.
As I've mentioned in a previous comment, setting the config_path to an inexistent file path will render a different error, at least from my experience.

[afdezl]

Hi, are there any timelines for this?

[aaronmell]

Hi, are there any timelines for this?

there is an open PR, needs review and to be merged by a maintainer. Then needs a release. I have no control over that part.

[Fryuni]

Nice work guys, I tested it on our environment and got the same error that @rowecharles mentioned in his last comment:

2020/01/04 21:34:55 [DEBUG] helm_release.nginx_ingress: apply errored, but we're indicating that via the Error pointer rather than returning it: Kubernetes cluster unreachable
2020/01/04 21:34:55 [TRACE] <root>: eval: *terraform.EvalMaybeTainted
2020/01/04 21:34:55 [TRACE] EvalMaybeTainted: helm_release.nginx_ingress encountered an error during creation, so it is now marked as tainted
2020/01/04 21:34:55 [TRACE] <root>: eval: *terraform.EvalWriteState
2020/01/04 21:34:55 [TRACE] EvalWriteState: removing state object for helm_release.nginx_ingress
2020/01/04 21:34:55 [TRACE] <root>: eval: *terraform.EvalApplyProvisioners
2020/01/04 21:34:55 [TRACE] EvalApplyProvisioners: helm_release.nginx_ingress has no state, so skipping provisioners
2020/01/04 21:34:55 [TRACE] <root>: eval: *terraform.EvalMaybeTainted
2020/01/04 21:34:55 [TRACE] EvalMaybeTainted: helm_release.nginx_ingress encountered an error during creation, so it is now marked as tainted
2020/01/04 21:34:55 [TRACE] <root>: eval: *terraform.EvalWriteState
2020/01/04 21:34:55 [TRACE] EvalWriteState: removing state object for helm_release.nginx_ingress
2020/01/04 21:34:55 [TRACE] <root>: eval: *terraform.EvalIf
2020/01/04 21:34:55 [TRACE] <root>: eval: *terraform.EvalIf
2020/01/04 21:34:55 [TRACE] <root>: eval: *terraform.EvalWriteDiff
2020/01/04 21:34:55 [TRACE] <root>: eval: *terraform.EvalApplyPost
2020/01/04 21:34:55 [ERROR] <root>: eval: *terraform.EvalApplyPost, err: Kubernetes cluster unreachable
2020/01/04 21:34:55 [ERROR] <root>: eval: *terraform.EvalSequence, err: Kubernetes cluster unreachable
2020/01/04 21:34:55 [TRACE] [walkApply] Exiting eval tree: helm_release.nginx_ingress
2020/01/04 21:34:55 [TRACE] vertex "helm_release.nginx_ingress": visit complete

The configuration is the exact same as the kubernetes provider and the resources there are working correctly:

provider "kubernetes" {
  version                = "~> 1.10"
  load_config_file       = false
  host                   = module.cluster.master_endpoint
  cluster_ca_certificate = base64decode(module.cluster.cluster_ca)
  token                  = data.google_client_config.default.access_token
}
provider "helm" {
  kubernetes {
    load_config_file       = false
    host                   = module.cluster.master_endpoint
    cluster_ca_certificate = base64decode(module.cluster.cluster_ca)
    token                  = data.google_client_config.default.access_token
  }
}

I rebased @relu 's hack branch upon #378 for this test. I'm trying to find the problem and hopefully the solution, but since it's my first time working with a terraform provider source I don't trust myself very much for this

[Fryuni]

Ok, I found the problem and a workaround. When the kubernetes client is being created it first check if the target ApiServer is secure (using TLS) and only then, if it is, load the authentication options (where the token is).

So the solution for my case, and probably @rowecharles, is to prepend https:// to the host:

provider "helm" {
  kubernetes {
    load_config_file       = false
    host                   = "https://${module.cluster.master_endpoint}"
    cluster_ca_certificate = base64decode(module.cluster.cluster_ca)
    token                  = data.google_client_config.default.access_token
  }
}

I didn't check what the kubernetes provider does differently for it to work with only the host

[relu]

The kubernetes provider uses a different rest client initialization mechanism.

While helm uses this (the same is being used in the provider as well).

The kubernetes provider client init also has an "insecure" attribute.

It looks like the TLS check you mentioned is done here and the implementation looks like it actually does check the scheme.

[chris-brace]

For anyone who's never done go development before but needs terraform to work with helm v3 i figured i'd post how im getting @aaronmell / @relu 's branches building locally. It's pretty simple.

export GOPATH="${HOME}/.go"
export GOROOT="$(brew --prefix golang)/libexec"
export PATH="$PATH:${GOPATH}/bin:${GOROOT}/bin"
test -d "${GOPATH}" || mkdir "${GOPATH}"
test -d "${GOPATH}/src/github.com" || mkdir -p "${GOPATH}/src/github.com"
brew install go
mkdir -p $GOPATH/src/github.com/terraform-providers
cd $GOPATH/src/github.com/terraform-providers/
git clone https://github.com/aaronmell/terraform-provider-helm.git
cd terraform-provider-helm
git checkout -t origin/dev-v3
make build
mkdir -p ~/.terraform.d/plugins
mv terraform-provider-helm ~/.terraform.d/plugins/terraform-provider-helm_v10.10

N.B.: the last line calls the built provider terraform-provider-helm_v10.10 which will cause it to automatically supersede the highest version of the current release when you do terraform init. This may or may not be the best approach but it works for me. Just note that you probably don't wanna go hardcoding this anywhere because its not a "real" version of the provider.

[jasonmcboyd]

@chris-brace Thanks, as somebody that does not program in go that was helpful. I created a Dockerfile from your example hat builds a terraform image with the helm 3 plugin:

ARG TERRAFORM_VERSION=0.12.20

FROM golang as build
RUN git clone https://github.com/aaronmell/terraform-provider-helm.git -- && \
    cd terraform-provider-helm && \
    git checkout -t origin/dev-v3 && \
    CGO_ENABLED=0 make build

FROM hashicorp/terraform:${TERRAFORM_VERSION}
RUN mkdir -p ~/.terraform.d/plugins
COPY --from=build /go/terraform-provider-helm/terraform-provider-helm /root/.terraform.d/plugins/terraform-provider-helm

[jakesyl]

@jasonmcboyd Thanks for adding this!

[jclynny]

Any updates on when this might be worked on / available? Helm v3.0.3 has been released, we're using Helm v3, would be nice if the Terraform provider supported it as that is so much nicer than doing it with null_resource blocks or an equivalent.

[doctapp]

Been a while and we also need it.
Thanks

On Fri, Jan 31, 2020 at 9:00 AM Josh Lynn [e-mail] wrote:

Any updates on when this might be worked on / available? Helm v3.0.3 has
been released, we're using it, would be nice if the Terraform provider
supported it as that is so much nicer than doing it with null_resource
blocks or an equivalent.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/terraform-providers/terraform-provider-helm/issues/299?email_source=notifications&email_token=AA3OUNFZ6U73V4B4KUDF76DRAQVGPA5CNFSM4H37Y7OKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKOXH3Y#issuecomment-580744175,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA3OUNCY6POHWNHR3H5KYKTRAQVGPANCNFSM4H37Y7OA
.

[chris-brace]

I'm pretty sure this is the PR: https://github.com/terraform-providers/terraform-provider-helm/pull/378 . It seems like ownership of this plugin just changed and someone is getting ramped up to own it at hashicorp.

[jrhouston]

This has landed in 1.0.0. Thanks for waiting everyone! 😄