Remote state - omitting env:/dev/

Terraform
1

My remote state for two of my projects automatically stores in env:/dev/state_path
However for two other projects, it is omitting the env:/dev/, I have had to manually add that env specification. These two projects didn’t need this, and then one day (after an update?) each eventually required me to manually add that.

Here is an example of one of the projects that has been affected by this

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  required_version = "~> 1.5.7"
}

provider "aws" {
  profile = "default"
  region  = var.region
}

data "aws_caller_identity" "current" {}

// INPUTS
data "terraform_remote_state" "builds_bucket" {
  backend = "s3"

  config = {
    bucket = "remote-state-bucket"
    // massive kluge
    key    = "env:/dev/builds_bucket/terraform.tfstate"
    region = "us-west-1"
    workspace_key_prefix="env"
  }
}

data "terraform_remote_state" "user_pool_bucket" {
  backend = "s3"

  config = {
    bucket = "remote-state-bucket"
    // massive kluge
    key    = "env:/dev/user_pool/terraform.tfstate"
    region = "us-west-1"
    workspace_key_prefix="env"
  }
}

// OUTPUTS
terraform {
  backend "s3" {
    bucket = "remote-state-bucket"
    key = "service/terraform.tfstate"
    region = "us-west-1"

    dynamodb_table = "terraform-remote-state-locks"
    encrypt        = true
  }
}

the second service that began to exhibit this behavior relies on the output of this. That’s one of the key frustrations: when it’s outputting to remote state it knows to add the env:/dev/, however on the inputs it’s requiring me to add them manually

2

Are you using terraform workspaces? You don’t state if this is running locally or via some sort of CI/CD pipeline. If the latter is something setting (or stopped setting) workspaces?

While I’m not familiar with the S3 backend however in the Azure backend when you use a workspace it adds an affix similar to what you show:

In the image below the state file at the top is after a terraform init without setting workspace (so the workspace = ‘default’)
The state file at the bottom is after a terraform init after issuing terraform workspace new dev which creates and changes into a workspace called dev.

image

HTH

Happy Terraforming

3

Yeah both of the repos which are omitting the affix are both using the terraform workspace dev. I’ve also tried adding a Prod workspace but no change.

I’m running this on my local machine

Here’s my terraform version. I upgraded this morning and was previously on v1.5.7. Unfortunately this upgrade still did not help

$ terraform version
Terraform v1.8.3
on darwin_arm64

I’ve also tried manually setting the TF_ENV variable which didn’t change anything either

Since it affixes the env:/dev/ when saving to the remote state, but not when reading from the remote state, it keeps making me think that it knows it’s supposed to use that environment but is omitting when retrieving state for other projects

4

The remote state data source that you are using has a workspace argument which you don’t appear to be using:

But you are passing the workspace_key_prefix parameter as part of the config block which should do the same job (at least for the s3 backend)

May be worth testing using the data source argument instead of the config parameter and see if that solve it. Although an unexpected change in behaviour is a bit concerning.

5

That did the trick!

I’m not sure why since 1/2 of my TF projects require neither the Workspace data value, nor workspace_key_prefix (I had attempted this when things stopped working)

I’m not going to look a gift-horse in the mouth though since this fixed my problem

that being said however it’s concerning that out of 4 projects with near identical configs, 2 of them -one after another- began omitting that affix

1 Like
6

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.