hashicorp / terraform-provider-tfe

Official HCP Terraform and Terraform Enterprise provider, maintained by HashiCorp. Provision HCP Terraform or Terraform Enterprise - with Terraform!
https://registry.terraform.io/providers/hashicorp/tfe
Mozilla Public License 2.0
160 stars 154 forks source link

TFE Provider fails to apply changes when workspaces are renamed under some conditions #120

Closed pkolyvas closed 4 years ago

pkolyvas commented 4 years ago

I've discovered an issue where renaming a workspace, via a variable map, causes an error on terraform apply, that is fixed by running a second apply.

Terraform Version

TFC via Terraform 0.12.20

Terraform Configuration Files

The TLDR of this config is that I'm provisioning/managing a TFC org and the associated workspaces, using for_each to populate the AWS creds for each workspace.

provider "tfe" {
  hostname = "app.terraform.io"
}

variable "my_aws_key_id" {
  type        = string
  description = "AWS Access key id"
}

variable "my_aws_access_key" {
  type        = string
  description = "AWS key"
}

variable "workspaces" {
  type = map
  default = {
    tfc_config  = "TFC_Config"
    zones       = "Route53_Zones"
    certs       = "Certificates"
    A_domains   = "Domains_Project_A"
    A_resources = "Resources_Project_A"
    B_domains   = "Domains_Project_B"
    B_resources = "Resources_Project_B"
    C_domains   = "Domains_Project_C"
    C_resources = "Resources_Project_C"
  }
}

resource "tfe_organization" "my-org" {
  name  = "org"
  email = "terraformcloud@myorg.org"
  lifecycle {
    prevent_destroy = true
  }
}

resource "tfe_workspace" "my-org_workspace" {
  for_each     = var.workspaces
  name         = each.value
  organization = tfe_organization.my-org.id
  lifecycle {
    prevent_destroy = true
  }
}

resource "tfe_variable" "aws_key_id" {
  for_each     = var.workspaces
  key          = "AWS_ACCESS_KEY_ID"
  value        = var.my_aws_key_id
  category     = "env"
  workspace_id = tfe_workspace.my-org_workspace[each.key].id
}

resource "tfe_variable" "aws_key" {
  for_each     = var.workspaces
  key          = "AWS_SECRET_ACCESS_KEY"
  value        = var.my_aws_access_key
  category     = "env"
  sensitive    = true
  workspace_id = tfe_workspace.my-org_workspace[each.key].id
}

Debug Output

I didn't catch one but it's repeatably so if I must, I will return with one. ;)

Crash Output

Error: Provider produced inconsistent final plan

When expanding the plan for tfe_variable.aws_key["c_domains"] to include
new values learned so far during apply, provider "registry.terraform.io/-/tfe"
produced an invalid new value for .workspace_id: was
cty.StringVal("my_org/C_Domains"), but now
cty.StringVal("my_org/Domains_C").

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

Error: Provider produced inconsistent final plan

When expanding the plan for tfe_variable.aws_key_id["b_domains"] to
include new values learned so far during apply, provider
"registry.terraform.io/-/tfe" produced an invalid new value for .workspace_id:
was cty.StringVal("my_org/B_Domains"), but now
cty.StringVal("my_org/Domains_B").

This is a bug in the provider, which should be reported in the provider's own
issue tracker..

Expected Behavior

When I change the value of a mapped variable, terraform apply should not fail.

Actual Behavior

terraform apply fails the first time with the above error. A second terraform apply works and my resources are in their expected state [pun totally intended].

Additional Context

If I were to change a var.workspaces.value from "My_Workspace" to "My_workspace" the workspace is renamed without issue during a terraform apply.

However, when I change a value of a var.workspace.value from "My_Workspace" to "Workspace_A" the two associated variables are not able to be destroyed and recreated on the first terrafrom apply. A second terraform apply is required.

mengesb commented 4 years ago

CHANGELOG.md v0.15.1

Perhaps this change helps with your situation?

beekus commented 4 years ago

This does appear to be fixed by v0.15.1. I was able to reproduce the issue using 0.15.0, and then I tried it with v0.15.1 and it worked as expected.

caseylang commented 4 years ago

Closing with the expectation that v0.15.1 resolves the issue.