CODEWITHSUNDEEP
azureterraform
JakeUT
JakeUT

Reputation: 537

Backend initialization required, please run "terraform init"

I had the following Terraform configuration for my backend that worked for a while,

terraform {
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
    }
  }

  backend "azurerm" {
    resource_group_name  = "my-rg"
    storage_account_name = "my-sa"
    ####!!!!! BELOW USED TO WORK !!!!###
    provider             = azurerm.mysub  
    key                  = "terraform.tfstate"
  }
}

provider "azurerm" {
  skip_provider_registration = true
  subscription_id            = "xxxxxx-xxxxx-xxxxx-xxxxx"  
  alias                      = "mysub"
  features {
  }
}

However after an upgrade it said that provider was not allowed in this block (I dont recall teh exact error message). So instead I changed it as such,

terraform {
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
    }
  }

  backend "azurerm" {
    resource_group_name  = "my-rg"
    storage_account_name = "my-sa"
    ###!!!! Direct Reference to Subscription ID !!!!###
    subscription_id      = "xxxxxx-xxxxx-xxxxx-xxxxx"  
    key                  = "terraform.tfstate"
  }
}

However now it says,

│ Error: Backend initialization required, please run "terraform init"
│
│ Reason: Backend configuration changed for "azurerm"
│
│ The "backend" is the interface that Terraform uses to store state,
│ perform operations, etc. If this message is showing up, it means that the
│ Terraform configuration you're using is using a custom configuration for
│ the Terraform backend.
│
│ Changes to backend configurations require reinitialization. This allows
│ Terraform to set up the new configuration, copy existing state, etc. Please run
│ "terraform init" with either the "-reconfigure" or "-migrate-state" flags to
│ use the current configuration.
│
│ If the change reason above is incorrect, please verify your configuration
│ hasn't changed and try again. At this point, no changes to your existing
│ configuration or state have been made.

If I want it to remember the state so that it knows how to destroy the same later, what command should I use? I have already deployed several iteration of resources in this RG using terraform and want to keep that intact.

terraform init, OR,

terraform init -reconfigure, OR,

terraform init -migrate-state??

Since the backend location has not changed, I want to continue as is but just have it ignore the backend block update from using "provider" to using the "subscription_id". Which command do I use?

Thanks in advance!

Upvotes: 1

Views: 28821

Answers (4)

remz
remz

Reputation: 1

If you are not expecting this error, it could also be that the previous state is being held on to - so a "rm -rf .terraform " and then doing the terraform init again may be the solution.

Upvotes: 0

Rotem jackoby
Rotem jackoby

Reputation: 22198

I'm adding another answer since the first one didn't solved the issue in my case.

Running:

terragrunt run-all plan --terragrunt-source-update

Worked for me.

From here:

Runs the provided terraform command against a stack, where a stack is a tree of terragrunt modules. The command will recursively find terragrunt modules in the current directory tree and run the terraform command in dependency order (unless the command is destroy, in which case the command is run in reverse dependency order).

Upvotes: 4

Martin Atkins
Martin Atkins

Reputation: 74604

The terraform init documentation says the following about this situation:

Re-running init with an already-initialized backend will update the working directory to use the new backend settings. Either -reconfigure or -migrate-state must be supplied to update the backend configuration.

The -migrate-state option will attempt to copy existing state to the new backend, and depending on what changed, may result in interactive prompts to confirm migration of workspace states. The -force-copy option suppresses these prompts and answers "yes" to the migration questions. This implies -migrate-state.

The -reconfigure option disregards any existing configuration, preventing migration of any existing state.

The decision point here is whether you want Terraform to take explicit action to try to copy the state to the new location (-migrate-state) or whether you want Terraform to just forget the old settings entirely and just use the new settings directly.

You said that the physical location is unchanged and instead you've just written the same information a different way, and so -reconfigure is the option that matches that situation: there's no need for any explicit migration here because the state is already available at the "new" location (which is functionally the same as the old location, but Terraform can't know that).

Note that it has never been valid to associate a backend configuration with a provider, so whatever you had working before wasn't working in the way you thought it was.

The azurerm backend has the behavior of looking for the ARM_SUBSCRIPTION_ID environment variable if you don't explicitly set subscription_id in its configuration, so I'd guess that you were previously running Terraform in a context where that environment variable was set and thus the backend was able to find the appropriate subscription ID to use even though you hadn't explicitly set it.

Why the backend wasn't rejecting the invalid argument provider is unclear to me. That suggests a bug in either Terraform or in the backend itself, which has since been fixed and thus Terraform is now correctly reporting that there is no argument provider declared in that backend's configuration schema.

Upvotes: 5

JakeUT
JakeUT

Reputation: 537

I am not sure if this is the proper way to do this, but I was able to get this resolved without the initialization message coming up anymore by updated the local terraform.tfstate file.

Changed this line

        "subscription_id": null,

to,

        "subscription_id": "xxxx-xxxx-xxxx-xxxx",

Upvotes: -1

Related Questions