The provider doesn't work well in CI environments where each step is run in a completely clean environment (i.e. Terraform Cloud/Enterprise). It expects state from the plan stage to be available (when doing a plan to file -> apply plan file workflow).
terraform version
Terraform v0.12.8
data "helm_repository" "incubator" {
name = "incubator"
url = "https://kubernetes-charts-incubator.storage.googleapis.com"
username = "none"
}
resource "helm_release" "aws_alb_ingress_controller" {
provider = helm.module
name = "alb-ingress-controller"
repository = "${data.helm_repository.incubator.metadata.0.name}"
chart = "aws-alb-ingress-controller"
namespace = "kube-system"
version = "0.1.10"
depends_on = ["module.mod_eks"]
set {
name = "clusterName"
value = var.cluster_name
}
set {
name = "autoDiscoverAwsRegion"
value = "true"
}
set {
name = "autoDiscoverAwsVpcID"
value = "true"
}
}
I didn't run terraform in debug because I doubt it would help with the current problem.
I did gather the state of the system at apply time. Below is the ~/.helm/repository/repositories.yaml file. As you can see, it's missing the incubator repo.
apiVersion: v1
generated: "2019-09-11T02:16:19.961453812Z"
repositories:
- caFile: ""
cache: /home/terraform/.helm/repository/cache/stable-index.yaml
certFile: ""
keyFile: ""
name: stable
password: ""
url: https://kubernetes-charts.storage.googleapis.com
username: ""
- caFile: ""
cache: /home/terraform/.helm/repository/cache/local-index.yaml
certFile: ""
keyFile: ""
name: local
password: ""
url: http://127.0.0.1:8879/charts
username: ""
The provider should have updated the repositories.yaml file during the apply phase
Error: repo incubator not found
and indeed the repo does not exist in the repositories.yaml file
The easiest way I can think of would be to run terraform plan -out=/path/to/plan.out in a docker container. Then run terraform apply /path/to/plan.out in a separate container that has the same plan output
This is all currently running in Terraform Cloud (Hosted Enterprise product). When it was running locally on my laptop, it was fine.
Seeing this as well on terraform cloud.
I've been seeing this everywhere on Terraform cloud.
It's becoming a major blocker for our Infrastructure upgrades on all environments including production.
Including some random "error: Unauthorized" messages. I believe this to be just an overall issue due to the design of this module.
I ran into this as well, and this is a working fix in my environment. Our helm provider was configured with a relative path for home, which appears to have been broken by Terraform 0.12.x. Switching to an absolute path resolved it.
Using a repo URL in repository param should work instead of using the data resource.
I've found the same problem still occurs on v1.0.0 of the provider as well, and I had to resort to using the repo URL, instead of the datasource.
I've found with v1.0.0 of the provider, with helm v3 not having the stable repo by default anymore, I was able to add this datasource and deploy nicely:
data "helm_repository" "stable" {
name = "stable"
url = "https://kubernetes-charts.storage.googleapis.com"
}
I think this is the same issue I have discussed here: https://github.com/terraform-providers/terraform-provider-helm/issues/416#issuecomment-598828730
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!
Most helpful comment
Using a repo URL in repository param should work instead of using the data resource.