Terraform root module deletion not working

[lakshayarora476]

I am trying to delete the terraform root modules, by directly removing the root modules. After I remove it and run terraform plan, I get an error:

 Error: Provider configuration not present
│
│ To work with module.index1.elasticstack_elasticsearch_index_lifecycle.ilm_policy (orphan) its original provider configuration at
│ module.index1.provider["registry.terraform.io/elastic/elasticstack"] is required, but it has been removed. This occurs when a provider configuration is
│ removed while objects created by that provider still exist in the state. Re-add the provider configuration to destroy
│ module.index1.elasticstack_elasticsearch_index_lifecycle.ilm_policy (orphan), after which you can remove the provider configuration again.

Below is the root module…

 module "index4" {
   source = "xyz"
   index_name    = "my_index_4"
   replicas      = 1
   ilm_retention = "90d"
   timestamp     = "date"
   space_name    = "test"
 }

I know I can use command terraform destroy -target=module.module_name
But I don’t want to do that way.
This should automatically work by terraform.

Can someone help me on this? I’m struggling since many weeks to resolve this issue.

Thank you!!

[apparentlymart]

Hi @lakshayarora476,

The term “root module” normally refers to the module in same directory where you run terraform apply. Any module called using a module block is not a root module.

But that terminology difference aside, it seems like you have got caught in the trap of having a provider block inside your non-root module, which is not recommended in the docs precisely because this situation occurs, and ideally it would be forbidden in the first place but unfortunately must remain allowed for backwards compatibility.

Using the -target option is the best way to immediately escape the trap. Once you are no longer trapped, you can avoid becoming trapped again by never writing a provider block inside a module you are calling with a module block. provider blocks should appear only in your root module, which again is the module in the directory where you run terraform apply.

I’m sorry for this mess. It is the historical design error in Terraform that I am most annoyed by, and hopefully one day it will be viable to make a breaking change so that this situation would be forbidden in the first place, or alternatively to find some way to track enough information in the state to configure the provider even when its provider block isn’t present. (But that’s not easy because providers often depend on time-limited credentials that would make no sense to remember in the state.)

[maxb]

An alternative workaround that is sometimes useful is to make a version of your child module (xyz in this example) that contains the provider block(s) but no resource block(s), and swap the module block’s source over to point to the “deletion mode” module variant for one terraform apply, before removing it entirely.

[lakshayarora476]

Hello,
Thanks for your answer.
However, I would like to tell you that I am using provider block in my root module only. ( Hopefully my naming convention is now correct )

Please take a look at the below screenshot on the files marked with RED pen.

index.tf contains the module blocks (these are child modules) which are calling the root modules ( code present in elasticsearchmodule/main.tf )

 module "index6" {
   source = "xyz"
   index_name    = "test_index_6"
   replicas      = 2
   ilm_retention = "90d"
   timestamp     = "date"
 }

elasticsearchmodule/main.tf (this is a sample code )

resource "xyz" "xyz" {
  name = xyz
  alias {
    name = xyz
  }
  mappings           = xyz
  number_of_shards   = xyz
  number_of_replicas = xyz
  
}

And I am running terraform commands in elasticsearch/ directory; where my index.tf file is present.
And as soon as I remove the module blocks from index.tf, I get those errors.

[lakshayarora476]

It would be great if you can explain with an example code
I am actually trying to automate this entirely, hence not willing to run any manual command in between.
Everything should be auto-created, updated and auto-destroyed using terraform in-built commands.
thank you

[maxb]

@lakshayarora476

Hopefully my naming convention is now correct

@lakshayarora476

index.tf contains the module blocks (these are child modules) which are calling the root modules ( code present in elasticsearchmodule/main.tf )

No, your naming convention is still the previous incorrect one you were using before.

The actual root module in your case is the directory containing backend.tf and index.tf.

[lakshayarora476]

Ok thank you for your answer.
I will remove the providers block from child modules and will put the providers block along with index.tf file.
I will then run the terraform commands and see if the error persists.

[lakshayarora476]

Hi,
I removed the provider from the child module ( from elasticsearchmodule directory in providers.tf) and put it in the root module ( in elasticsearch directory along with index.tf ).

I get below error when I run terraform init

Below is my index.tf file

terraform {
  required_providers {
    elasticstack = {
      source  = "elastic/elasticstack"
      version = "0.5.0"
    }
    elasticsearch = {
      source  = "phillbaker/elasticsearch"
      version = "2.0.7"
    }
  }
}

provider "elasticstack" {
  elasticsearch {
    username  = var.username
    password  = var.password
    endpoints = ["my_elastic_cluster_endpoint"]
    insecure  = true
  }
}

provider "elasticsearch" {
  url         = "my_elastic_cluster_endpoint"
  alias       = "elastic"
  healthcheck = false
  insecure    = true
  username    = var.username
  password    = var.password
}

module "index1" {
  source        = "../elasticsearchmodule"
  index_name    = "my_index_name"
  replicas      = 1
  ilm_retention = "xyz"
  timestamp     = "date"
  space_name    = "xyz"
}

[maxb]

You removed too much:

• Provider configurations - provider blocks - should be in the root module only.

• Declarations of required providers - terraform { required_providers { } } blocks - are needed in every module where they are relevant, because:

  • Different modules could express stricter or more relaxed version constraints

  • Different modules could (theoretically) have a different mapping between provider local name and fully qualified provider ID.

[lakshayarora476]

Thank you so much for your help.
I was able to overcome the problem by restructuring my code.