Terraform-provider-helm: not respecting kubernetes provider passed to module

[kim0]

Terraform Version

Terraform v0.12.0
+ provider.azuread v0.3.1
+ provider.azurerm v1.29.0
+ provider.helm v0.9.1
+ provider.kubernetes v1.7.0
+ provider.random v2.1.2

Affected Resource(s)

• helm provider

Terraform Configuration Files

# snip other stuff ...

# Define k8s provider with alias
provider kubernetes {
  alias                  = "regionk8s"
  host                   = module.k8s.cluster_host
  client_certificate     = base64decode(module.k8s.client_certificate)
  client_key             = base64decode(module.k8s.client_key)
  cluster_ca_certificate = base64decode(module.k8s.cluster_ca_certificate)
  load_config_file       = false
}

# use it to create simple k8s resources (secret) .. works!
module "tls" {
  source = "../tls"
  providers = {
    kubernetes = "kubernetes.regionk8s"
  }

}

# but use it with helm .. does not
module "helm" {
  source = "../helm"
  providers = {
    kubernetes = "kubernetes.regionk8s"
  }

  tiller_image = "gcr.io/kubernetes-helm/tiller:v2.14.0"
}

Expected Behavior

My helm module (which uses the helm provider) should pickup the kubernetes provider passed (alias regionk8s) and use that!

Actual Behavior

Error: stat /Users/kim0/.kube/config: no such file or directory

  on modules/helm/main.tf line 1, in provider "helm":
   1: provider "helm" {

[meyskens]

Can you get us the content of the module?

[kim0]

@meyskens Thanks for taking a look. HYG, main.tf only has the below 2 lines (which I'm hoping are enough)

provider "helm" {
    tiller_image = "${var.tiller_image}"
    max_history = 50
}

and in adjacent files regular helm_releases like

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

  chart      = "nginx-ingress"
  repository = data.helm_repository.stable.name
  version    = "1.6.13"

[17twenty]

I had a similar issue after nesting the module - i ended up just declaring the provider at top level AND in the module.

[jeremych1000]

+1 - I've tried explicitly saying load_config_file = false, along with setting the config context.

Terraform just ignores all of it, and instead uses what is currently defined in my ~/.kube/config, which caused me to accidentally deploy something into the wrong cluster :P

[jeremych1000]

I had a similar issue after nesting the module - i ended up just declaring the provider at top level AND in the module.

Does that solve the problem? Am I correct in saying you would then pass the kubeconfig as variables into the helm module, like any other variable?

How does terraform init work?

[isen-ng]

I think it's better to support this use-case of directly passing in the kubernetes provider. Duplicating the kubernetes provider values inside the helm provider is not a long term solution.

The kubernetes provider started supporting the exec block a while ago, but the copied provider in helm does not yet support it as of today. (https://github.com/terraform-providers/terraform-provider-kubernetes/commit/64973a4a0368ee7e39fe03e1af2a10e77dd1851c#diff-da3a5957d1adf1d97d4dec9f43b36ec1)

Having a duplicate of the provider just makes this helm terraform provider play a catch up game to all the new features of the kubernetes provider.

[isen-ng]

Hmm it seems like the kubernetes block is only used when installing tiller and connecting to remote tiller.

However, coming helm v3 (tillerless helm), helm will have to communicate directly to the kubernetes API, coupling this and the kubernetes provider tighter. This means that the race to catch up is even more pressing if the kubenetes block is still being duplicated in the helm provider block.

[kim0]

Is there an actual fix expected soon? anyone from the dev team around to comment please? Thanks

[syedhassaanahmed]

+1 to this feature. Kubernetes provider is quite often used in conjunction with Helm provider, lets make sure the DRY rule applies here.

[mcuadros]

Closing this issue since is making reference to a version based on Helm 2, if this is still valid to the master branch please reopen it. Thanks.

[syedhassaanahmed]

@mcuadros The issue is still valid imo. Please see @isen-ng comment above regarding Helm 3

However, coming helm v3 (tillerless helm), helm will have to communicate directly to the kubernetes API, coupling this and the kubernetes provider tighter. 
This means that the race to catch up is even more pressing if the kubenetes block is still being duplicated in the helm provider block.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!