Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

helm cannot find remote module after terraform destroy when using previous terraform state #662

Closed
tantweiler opened this issue Jan 16, 2021 · 8 comments

Comments

@tantweiler
Copy link

tantweiler commented Jan 16, 2021

Terraform version: 0.14.4
Provider version: v2.0.1
Kubernetes version: AKS 1.18.14
Helm version: 3.5.0

Steps to Reproduce

I created a pipeline in GitLab with terraform modules which use the providers azurerm, kubernetes and helm. The modules are located in remote GitLab projects and are being imported via git:

module "helm" {
  source            = "git::https://gitlab.mydomain.com/terraform-modules/azure/helm.git?ref=v1.0"
}

If the pipeline starts with a fresh or empty state, the provider is able to import the module as expected. When I run the "terraform destroy" stage in my pipeline and want to restart the pipeline afterwards so that the environment is being set up again, the helm provider complains that the helm releases I would like to install do not exists:

Warning: Release does not exist
Release name: nginx-ingress does not exist. It may have been deleted outside
of Terraform
Warning: Release does not exist
Release name: nginx-ingress-internal does not exist. It may have been deleted
outside of Terraform
Warning: Release does not exist
Release name: cert-manager does not exist. It may have been deleted outside of
Terraform
Warning: Release does not exist
Release name: cert-mgr-clusterissuers does not exist. It may have been deleted
outside of Terraform
Warning: Release does not exist
Release name: prometheus-operator does not exist. It may have been deleted
outside of Terraform

All the the other providers (azurerm and kubernetes) are able to reuse the terraform state and redeploy their resources. The only way to fix this issue for the helm provider is to delete the state.

If I use a local modules repository instead of a remote modules repository this issue doe snot occur!

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
@tantweiler tantweiler added the bug label Jan 16, 2021
@IceBear2k
Copy link

Ran into the same issue. Temporary workaround that works for me is downgrading to 1.3.2 as 2.0.0 is also affected:

terraform {
  required_providers {
    helm = {
      source = "hashicorp/helm"
      # FIXME: Pinned version due to Helm provider bug in 2.0.0 & 2.0.1 regarding existing Terraform state
      # "Warning: Release does not exist"
      # See: https://github.com/hashicorp/terraform-provider-helm/issues/662
      version = "= 1.3.2"
    }
}

@maurelio1234
Copy link

I have the same problem, we have a couple of charts installed with the helm provider.
When we uninstall them with helm uninstall the provider is not able to reinstall them again.

I was forced to revert to v1.3.2 again.

@kaskavalci
Copy link

In our case downgrading did not work. We had to remove helm release from tfstate file and terraform happily recreated the release. This is a dangerous operation as it may break your terraform state. We did it on a dev env with no impact.

@romankydybets
Copy link

the same is happens for me.

@jrhouston
Copy link
Contributor

#674 should fix this

@larssb
Copy link

larssb commented Feb 10, 2021

Then we just patiently wait for this to get out 👍

@github-actions
Copy link

Marking this issue as stale due to inactivity. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. This helps our maintainers find and focus on the active issues. Maintainers may also remove the stale label at their discretion. Thank you!

@github-actions
Copy link

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants