Configuring provider using another resource's outputs is not possible anymore since v2.0.0

[mcanevet]

Terraform, Provider, Kubernetes and Helm Versions

Terraform version: 0.14.3
Provider version: 2.0.0
Kubernetes version: 1.8.x
Helm version: 3.4.x

Affected Resource(s)

• helm_release
• helm_repository

Error: provider not configured: you must configure a path to your kubeconfig
or explicitly supply credentials via the provider block or environment variables.

See our documentation at: https://registry.terraform.io/providers/hashicorp/helm/latest/docs#authentication

Expected Behavior

With provider < 2.x I used to create an AKS or EKS cluster and deploy some helm charts in the same terraform workspace, configuring Helm provider with credentials coming from Azure or AWS' specific resources to create the Kubernetes cluster.
It looks like this is not possible anymore.

Actual Behavior

Important Factoids

It used to with with v1.x

References

• 🌱 Bump k8s.io/client-go from 0.27.1 to 0.28.1 #1234

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[jrhouston]

Thanks for opening this @mcanevet can you share the config you used to configure the provider?

I suspect this might be a bug in some additional validation we added when the provider gets configured.

[dwaiba]

Same error with the following:

terraform {
  required_version = ">= 0.14.3"
  required_providers {
    helm = {
      version = ">=1.3.2"
    }
    null = {
      version = ">=3.0.0"
    }
  }
}
provider "helm" {
  kubernetes {
    host                   = lookup(var.k8s_cluster, "host")
    client_certificate     = base64decode(lookup(var.k8s_cluster, "client_certificate"))
    client_key             = base64decode(lookup(var.k8s_cluster, "client_key"))
    cluster_ca_certificate = base64decode(lookup(var.k8s_cluster, "cluster_ca_certificate"))

  }
}

Works fine with the following and hence an issue with 2.0.0

terraform {
  required_version = ">= 0.14.3"
  required_providers {
    helm = {
      version = "=1.3.2"
    }
    null = {
      version = ">=3.0.0"
    }
  }
}
provider "helm" {
  kubernetes {
    host                   = lookup(var.k8s_cluster, "host")
    client_certificate     = base64decode(lookup(var.k8s_cluster, "client_certificate"))
    client_key             = base64decode(lookup(var.k8s_cluster, "client_key"))
    cluster_ca_certificate = base64decode(lookup(var.k8s_cluster, "cluster_ca_certificate"))

  }
}

[jrhouston]

I've put out a patch release that moves the validation logic so it happens after the provider is configured and should remedy this issue. Please let me know if this error is still surfacing for you.

[mprimeaux]

@jrhouston Thanks for your help. I am experiencing the same issue as identified by @mcanevet even when using the Terraform Helm provider 2.0.1 patch, which I believe represents this commit.

Execution of the 'terraform plan' phase results in the following error:

Error: provider not configured: you must configure a path to your kubeconfig
or explicitly supply credentials via the provider block or environment variables.

See our authentication documentation at: https://registry.terraform.io/providers/hashicorp/helm/latest/docs#authentication

To provide context, I'm spinning up a new AKS cluster as the first phase of our environment formation. The second phase of Terraform modules is focused on workload installation using the Helm provider.

I'm using Terraform 0.14.3, Azure RM provider 2.41.0 and the Terraform Helm provider v2.0.1. Any insights are appreciated. I can, of course, package any logs needed.

I'll start to debug back from this line as it seems to be the source of the error message.

[jrhouston]

@mprimeaux Thanks for getting back to me. Are you able to share a gist with more of your config? I have a config similar to the one posted above, and broken into two modules with one for the cluster and one for the charts but I can't get it to error.

If you are set up to build the provider you could also try commenting out these lines:

terraform-provider-helm/helm/provider.go

Lines 359 to 361 in 9de5e32

	if err := checkKubernetesConfigurationValid(m.data); err != nil {
	return nil, err
	}

If the plan still doesn't succeed then I suspect this is similar to the progressive apply issue we had in the kubernetes provider which is documented here.

Did you have load_config_file set to false in the kubernetes block when using v1.x.x? If not try setting that to false and see if you get an error, it could be that in v1.x.x the plan is succeeding because it's reading your local kubeconfig by default.

[mcanevet]

Looks like it works for me with v2.0.1.
Thanks.
Should I let this issue open, as it s unclear if the problem is really solved?

[jrhouston]

@mcanevet Thanks for reporting back. We can leave this open for now in case anyone else has issues with this.

[mprimeaux]

@jrhouston After a bit of debugging, I am pleased to report the 2.0.1 patches does indeed work as intended. I no longer experience the error as per above. We'll test a bit more across various formations and report back should we hit another exception case.

In the near term, we are modifying our formation strategy to reflect infrastructure formation, workload deployment and workload upgrade phases to gracefully avoid the 'pain'.

Sincerely appreciate everyone's help on this one.

[jrhouston]

Glad to hear that @mprimeaux! 😄 Thanks for contributing, please open issues generously if you run into any more problems.

[FischlerA]

@jrhouston Hi there,
i'm sorry but for me the issue isn't fixed, as the provider no longer looks for the kubeconfig file in the default path "~/.kube/config" as the old version did.
So far i relied on not having to specify the default path for the config file.
Any chance this will be readded?

[jrhouston]

@FischlerA is there a reason you can't explicitly specify config_path or set the KUBE_CONFIG_PATH environment variable?

We offer some context for why we made this breaking change in the Upgrade Guide.