Provider produced inconsistent final plan / an invalid new value for .tags_all #19583

chgasparoto · 2021-05-30T07:11:03Z

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform AWS Provider Version

Terraform v0.15.4
on darwin_amd64

provider registry.terraform.io/hashicorp/archive v2.2.0
provider registry.terraform.io/hashicorp/aws v3.42.0
provider registry.terraform.io/hashicorp/null v3.1.0

Affected Resource(s)

aws_vpc
aws_subnet

Terraform Configuration Files

Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key: https://keybase.io/hashicorp

# https://github.com/chgasparoto/youtube-cleber-gasparoto/tree/main/0002-terraform-lambda-layer

terraform {
  required_version = "0.15.4"
}

provider "aws" {
  region  = var.aws_region
  profile = var.aws_profile

  default_tags {
    tags = {
      Project   = "Lambda Layers with Terraform"
      CreatedAt = formatdate("YYYY-MM-DD", timestamp())
      ManagedBy = "Terraform"
      Owner     = "Cleber Gasparoto"
    }
  }
}
resource "aws_vpc" "example" {
  cidr_block = "10.1.0.0/16"
  tags = {
    Name = "my-vpc-resource"
  }
}
resource "aws_subnet" "example" {
  cidr_block = "10.1.1.0/24"
  vpc_id     = aws_vpc.example.id
  tags = {
    Name = "my-subnet-resource"
  }
}

Debug Output

aws_iam_role.cat_api_lambda: Modifications complete after 1s [id=cat-api-lambda-role]
aws_lambda_function.cat_api: Modifying... [id=cat_api]
aws_lambda_function.cat_api: Modifications complete after 0s [id=cat_api]
╷
│ Error: Provider produced inconsistent final plan
│
│ When expanding the plan for aws_vpc.example to include new values learned so far during apply, provider
│ "registry.terraform.io/hashicorp/aws" produced an invalid new value for .tags_all: new element "CreatedAt" has
│ appeared.
│
│ 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 aws_vpc.example to include new values learned so far during apply, provider
│ "registry.terraform.io/hashicorp/aws" produced an invalid new value for .tags_all: new element "ManagedBy" has
│ appeared.
│
│ 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 aws_vpc.example to include new values learned so far during apply, provider
│ "registry.terraform.io/hashicorp/aws" produced an invalid new value for .tags_all: new element "Owner" has
│ appeared.
│
│ 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 aws_vpc.example to include new values learned so far during apply, provider
│ "registry.terraform.io/hashicorp/aws" produced an invalid new value for .tags_all: new element "Project" has
│ appeared.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Panic Output

Expected Behavior

VPC and Network created with default tags successfully

Actual Behavior

VPC and Network are not created

Steps to Reproduce

terraform apply

Important Factoids

References

#0000

The text was updated successfully, but these errors were encountered:

anGie44 · 2021-06-01T18:00:00Z

Thank you for reporting this issue @chgasparoto ! This seems related to the the apply-time computed tag, CreatedAt , unfortunately. I'm seeing the terraform plan isn't correctly calculating the tags_all attribute as it technically should either include all the possible tags (default_tags + resource tags) or suggest the map is known after apply:

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_subnet.example will be created
  + resource "aws_subnet" "example" {
      + arn                             = (known after apply)
      + assign_ipv6_address_on_creation = false
      + availability_zone               = (known after apply)
      + availability_zone_id            = (known after apply)
      + cidr_block                      = "10.1.1.0/24"
      + id                              = (known after apply)
      + ipv6_cidr_block_association_id  = (known after apply)
      + map_public_ip_on_launch         = false
      + owner_id                        = (known after apply)
      + tags                            = {
          + "Name" = "my-subnet-resource"
        }
      + tags_all                        = {
          + "Name" = "my-subnet-resource"
        }
      + vpc_id                          = (known after apply)
    }

  # aws_vpc.example will be created
  + resource "aws_vpc" "example" {
      + arn                              = (known after apply)
      + assign_generated_ipv6_cidr_block = false
      + cidr_block                       = "10.1.0.0/16"
      + default_network_acl_id           = (known after apply)
      + default_route_table_id           = (known after apply)
      + default_security_group_id        = (known after apply)
      + dhcp_options_id                  = (known after apply)
      + enable_classiclink               = (known after apply)
      + enable_classiclink_dns_support   = (known after apply)
      + enable_dns_hostnames             = (known after apply)
      + enable_dns_support               = true
      + id                               = (known after apply)
      + instance_tenancy                 = "default"
      + ipv6_association_id              = (known after apply)
      + ipv6_cidr_block                  = (known after apply)
      + main_route_table_id              = (known after apply)
      + owner_id                         = (known after apply)
      + tags                             = {
          + "Name" = "my-vpc-resource"
        }
      + tags_all                         = {
          + "Name" = "my-vpc-resource"
        }
    }

matiu2 · 2021-06-02T22:21:07Z

If anyone figures out a work around in the meantime, please paste it here.

matiu2 · 2021-06-02T22:36:19Z

My work around is:

Comment out the default_tags block
Build
Uncomment the default_tags block
re-apply

anGie44 · 2021-06-03T15:29:55Z

Hi @matiu2 , thank you for following up on this issue! I don't believe there is a current workaround when using an apply-time Computed key/value pair like CreatedAt = timestamp() . I'm curious, in the workaround you've provided, were you also working with dynamic tag values in the default_tags.tags block?

Following the steps you've provided, if I'm using a timestamp value in the default_tags block, the final apply will not produce any modifications to the resource unfortunately as terraform won't detect the changes in the default_tags block even though it has been uncommented. The reason being that internally, the default_tags block is read as an empty map during run time (as it's marked as Computed just by having that one timestamp() tag for example), and merging the resource tags (in the example, Name="my-subnet-resource" etc.) on top of that empty map leaves us with no diff as it represents the original map.

ashraf133 · 2021-06-07T09:34:57Z

Hello,
Same problem for me while addind a tag "Name" which is not a part of default tags :

RESOURCE :

resource "aws_ami_copy" "server_encrypted" {
  name              = format("encrypted-server-ami.%s", local.timestamp_sanitized)
  description       = format("server (encrypted) created on : %s", local.timestamp_sanitized)
  source_ami_id     = data.aws_ami.latest_server.id
  source_ami_region = var.region
  encrypted         = true
  kms_key_id        = var.kms_key_id

  tags = {
    Name      = format("encrypted-server-ami.%s", local.timestamp_sanitized)
  }
}

PROVIDER :

provider "aws" {
  region = var.region
 default_tags {
  tags = {
   Owner     = var.Owner
   Stage     = var.Stage
   Project   = var.Project
   ManagedBy = var.ManagedBy
   Region    = var.region
  }
}
}

ERROR

Error: Provider produced inconsistent final plan
When expanding the plan for aws_ami_copy.server_encrypted to include
new values learned so far during apply, provider
"registry.terraform.io/hashicorp/aws" produced an invalid new value for
.tags_all: new element "Name" has appeared.
This is a bug in the provider, which should be reported in the provider's own
issue tracker.

Regards

Marinaburkhardt · 2021-06-09T12:17:56Z

Hi, same error here when adding an extra "Name" tag to a S3 bucket.

Used versions

terraform_version: 0.14.9
provider: registry.terraform.io/hashicorp/aws v3.39.0

Expected Behavior

S3 bucket created with default tags + customized tags successfully

Actual Behavior

S3 bucket is not created

Code snippet

provider "aws" {
  profile = var.aws_profile
  region  = var.aws_region

  default_tags {
    tags = {
      Created_by = "Terraform"
      Project    = "AWS_demo_fullstack_devops"
    }
  }
}

resource "aws_s3_bucket" "s3_bucket" {
  bucket        = var.bucket_name
  acl           = "private"
  force_destroy = true
  tags = {
    Name = var.bucket_name
  }
}

Plan output

  # module.s3_assets.aws_s3_bucket.s3_bucket will be created
  + resource "aws_s3_bucket" "s3_bucket" {
      + acceleration_status         = (known after apply)
      + acl                         = "private"
      + arn                         = (known after apply)
      + bucket                      = (known after apply)
      + bucket_domain_name          = (known after apply)
      + bucket_regional_domain_name = (known after apply)
      + force_destroy               = true
      + hosted_zone_id              = (known after apply)
      + id                          = (known after apply)
      + region                      = (known after apply)
      + request_payer               = (known after apply)
      + tags                        = (known after apply)
      + tags_all                    = {
          + "Created_by" = "Terraform"
          + "Project"    = "AWS_demo_fullstack_devops"
        }
      + website_domain              = (known after apply)
      + website_endpoint            = (known after apply)

      + versioning {
          + enabled    = (known after apply)
          + mfa_delete = (known after apply)
        }
    }

Error output (during apply)

Error: Provider produced inconsistent final plan

When expanding the plan for module.s3_assets.aws_s3_bucket.s3_bucket to
include new values learned so far during apply, provider
"registry.terraform.io/hashicorp/aws" produced an invalid new value for
.tags_all: new element "Name" has appeared.

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

Regards,
Mari

anGie44 · 2021-06-09T13:26:47Z

Thank you for providing additional context @ashraf133 and @Marinaburkhardt ! In both cases seems having a resource tags set with a var is not not being picked (by tags_all, though presumably it's in the similar situation where the tag value is known_after_apply) 😞. Will add this to the investigation 👍

anniehedgpeth · 2021-06-11T20:34:15Z

I just ran into the same issue here with config from this pull request running in this workspace.
Terraform v0.14.9
hashicorp/aws v3.45.0

Update: I received the same error when I removed the computed Environment value and made it hardcoded. This error is complaining about adding additional tags on individual resources like this, but yes, it's also using the random id, like Environment was in the last commit. When I removed the tags that were computed with random_id in favor of hardcoded values (i.e. this commit), my module succeed here.

Marinaburkhardt · 2021-06-14T09:33:20Z

Error seems to be fixed, I retried the deployment and now it worked. But the output doesn't show up as expected:

Apply output:

# module.s3_assets.aws_s3_bucket.s3_bucket will be created
  + resource "aws_s3_bucket" "s3_bucket" {
      + acceleration_status         = (known after apply)
      + acl                         = "private"
      + arn                         = (known after apply)
      + bucket                      = "assets-eu-central-1-4dc5"
      + bucket_domain_name          = (known after apply)
      + bucket_regional_domain_name = (known after apply)
      + force_destroy               = true
      + hosted_zone_id              = (known after apply)
      + id                          = (known after apply)
      + region                      = (known after apply)
      + request_payer               = (known after apply)
      + tags                        = {
          + "Name" = "assets-eu-central-1-4dc5"
        }
      + tags_all                    = {
          + "Created_by" = "Terraform"
          + "Name"       = "assets-eu-central-1-4dc5"
          + "Project"    = "AWS_demo_fullstack_devops"
        }
      + website_domain              = (known after apply)
      + website_endpoint            = (known after apply)

      + versioning {
          + enabled    = (known after apply)
          + mfa_delete = (known after apply)
        }
    }

I think the "Name" tag shouldn't be listed under tags_all und just under tags instead, since it's just a resource tag (see the code snippet used above in my previous comment).

Hope that helps 😄

sorengraungaard · 2021-06-14T12:03:54Z

@Marinaburkhardt the one resource type I don't have this problem with is S3 buckets, lots of other resource have this problem for me (RDS, Route53, Elasticsearch, cognito, and others)

share-me · 2021-06-22T09:20:59Z

Same for me, how to upvote for this issue?

How to Fix: just launch again
(but this solution doesn't fit for a Jenkins/Gitlab chain)

module.mq04.aws_mq_broker.mq: Creation complete after 9m54s [id=b-581xxx7d-xxxx-xxxx-xxxx-14547xx12345]

Error: Provider produced inconsistent final plan

When expanding the plan for module.rds01.aws_db_subnet_group.postgresql to
include new values learned so far during apply, provider
"registry.terraform.io/hashicorp/aws" produced an invalid new value for
.tags_all: new element "Name" has appeared.

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

$ terraform version
Terraform v0.13.7
+ provider registry.terraform.io/hashicorp/aws v3.46.0

rtoma · 2021-06-28T09:45:03Z

Another case where this bug hurts, using the ALB module https://registry.terraform.io/modules/terraform-aws-modules/alb/aws/latest

Error: Provider produced inconsistent final plan

When expanding the plan for
module.xxxxxxxx[0].module.alb.aws_lb_listener.frontend_https[0]
to include new values learned so far during apply, provider
"registry.terraform.io/hashicorp/aws" produced an invalid new value for
.tags_all: new element "Name" has appeared.

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

From plan. Note the code attempts to add a Name tag to tags causing the

  # module.xxxxxxx[0].module.alb.aws_lb_listener.frontend_https[0] will be created
  + resource "aws_lb_listener" "frontend_https" {
      + alpn_policy       = (known after apply)
      + arn               = (known after apply)
      + certificate_arn   = (known after apply)
      + id                = (known after apply)
      + load_balancer_arn = (known after apply)
      + port              = 443
      + protocol          = (known after apply)
      + ssl_policy        = (known after apply)
      + tags              = (known after apply)
      + tags_all          = {
                       (all provider level tags here)
        }

      + default_action {
          + order            = (known after apply)
          + target_group_arn = (known after apply)
          + type             = (known after apply)
        }
      + default_action {
          + order            = (known after apply)
          + target_group_arn = (known after apply)
          + type             = (known after apply)
        }
    }

My versions:

$ tf version
Terraform v0.13.5
+ provider registry.terraform.io/hashicorp/aws v3.40.0

tuxtek · 2021-07-06T18:30:22Z

I ran into this with the AWS EKS module as well.

Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for module.eks.aws_security_group.workers[0] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an
│ invalid new value for .tags_all["Name"]: was cty.StringVal("Shawn EKS Testing"), but now cty.StringVal("Shawn EKS Testing-GEyDNwpt-eks_worker_sg").
│ 
│ 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 module.eks.aws_security_group.workers[0] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an
│ invalid new value for .tags_all: new element "kubernetes.io/cluster/Shawn EKS Testing-GEyDNwpt" has appeared.
│ 
│ 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 module.eks.aws_security_group.cluster[0] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an
│ invalid new value for .tags_all["Name"]: was cty.StringVal("Shawn EKS Testing"), but now cty.StringVal("Shawn EKS Testing-GEyDNwpt-eks_cluster_sg").
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: invalid value for name_prefix (must match [\w+=,.@-])
│ 
│   with module.eks.aws_iam_role.cluster[0],
│   on .terraform/modules/eks/cluster.tf line 121, in resource "aws_iam_role" "cluster":
│  121:   name_prefix           = var.cluster_name
│ 
╵
╷
│ Error: invalid value for name_prefix (must match [\w+=,.@-])
│ 
│   with module.eks.aws_iam_policy.cluster_elb_sl_role_creation[0],
│   on .terraform/modules/eks/cluster.tf line 167, in resource "aws_iam_policy" "cluster_elb_sl_role_creation":
│  167:   name_prefix = "${var.cluster_name}-elb-sl-role-creation"
│

For my own instance of this, I was able to resolve it by removing the space in the tag.Name value I was using and replace with - instead. Ideally, it would have been good to see this warning in the plan. While resolved, I am sharing case this applies to any other use cases.

My Version:

Terraform v1.0.1

sneha43sweety · 2021-07-09T11:14:57Z

declare the default tags as local variable
locals {
common_tags = {
createdby = "me"
createdon = formatdate("MM/DD/YYYY", timestamp())
purpose = "test"
environment = "dev"
buildby = "automation"
}
}
and in each resource where u must be adding the name append this also
tags = { for k, v in merge({ "Name" = "test-vpc-1"},local.common_tags) : k => v }

jgeurts · 2021-07-21T02:52:48Z

I ran into this with the rds cluster resource. Terraform v1.0.2 and aws provider v3.50.0:

provider "aws" {
  region              = var.aws_region
  allowed_account_ids = [var.aws_account_id]

  default_tags {
    tags = {
      Terraform = "true"
    }
  }
}

resource "aws_rds_cluster" "clone" {
  ...

  tags = {
    Name    = "clone"
    Created = timestamp()
  }
}

Error: Provider produced inconsistent final plan

When expanding the plan for
module.db_clone.aws_rds_cluster.clone to include new 
values learned so far during apply, provider
"registry.terraform.io/hashicorp/aws" produced an invalid new value for
.tags_all: new element "Name" has appeared.

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

sneha43sweety · 2021-07-21T04:43:23Z

I ran into this with the rds cluster resource. Terraform v1.0.2 and aws provider v3.50.0:

provider "aws" {
  region              = var.aws_region
  allowed_account_ids = [var.aws_account_id]

  default_tags {
    tags = {
      Terraform = "true"
    }
  }
}

resource "aws_rds_cluster" "clone" {
  ...

  tags = {
    Name    = "clone"
    Created = timestamp()
  }
}

Error: Provider produced inconsistent final plan

When expanding the plan for
module.db_clone.aws_rds_cluster.clone to include new 
values learned so far during apply, provider
"registry.terraform.io/hashicorp/aws" produced an invalid new value for
.tags_all: new element "Name" has appeared.

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

Please remove the default tags and put that tag in local variable.
With each resource merge the local variable along with resource tag. Its one of the workaround

sarangk39 · 2021-07-21T06:21:34Z

We are upgrading to Terraform v0.12.31 and AWS provider v3.38.0

Our current terraform configuration looks like this -

provider aws {
version = “3.38.0”
}

locals {
common_tags = {
Source = var.source_tag
Team = var.owner_tag
Lifecycle = var.lifecycle_tag
Project = var.project_tag
EnvironmentType = var.environment_type_tag
Environment = var.environment_id
Contact = var.contact_tag
}
}

resource aws_dynamodb_table xyz {
tags = local.common_tags
}

Code output -

aws_dynamodb_table.xyz will be updated in-place
resource "aws_dynamodb_table" "xyz" {
tags= {} (known after apply)
tags_all = {}

When we run the terraform files, getting below error -

Provider produced inconsistent final plan
When expanding the plan for aws_dynamodb_table.xyz to
include new values learned so far during apply, provider
“registry.terraform.io/-/aws” produced an invalid new value for .tags_all: new element “Contact” has appeared.
This is a bug in the provider, which should be reported in the provider’s own issue tracker.

The same configuration works when we manually delete the existing Dynamo DB table and re-run the files. But we want to avoid getting this error in first place. What changes do we need to make in our files to avoid this error ?

Code output (when tables are deleted manually) -

aws_dynamodb_table.xyz will be created
resource "aws_dynamodb_table" "xyz" {
tags = (known after apply)
tags_all = (known after apply)

inhumantsar · 2021-08-05T21:45:09Z

I ran into the same error with the aws_security_group resource in the terraform-aws-modules/security-group/aws module: https://github.com/terraform-aws-modules/terraform-aws-security-group/blob/master/main.tf#L11-L25

│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for module.development_public_alb_sg.aws_security_group.this_name_prefix[0] 
to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an
│ invalid new value for .tags_all: new element "Name" has appeared.
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

❯ terraform --version
Terraform v1.0.1
on darwin_amd64
+ provider registry.terraform.io/hashicorp/aws v3.44.0
+ provider registry.terraform.io/hashicorp/random v3.1.0

I was able to work around the error by re-running terraform apply.

cmd-werner-diers · 2021-08-10T07:19:27Z

Sam issue for me

kihom-77 · 2021-08-11T15:01:13Z

For those who face this issue with a default tag value set to timestamp().

To avoid this problem I use a variable that contains the timestamp which is set just prior to the apply.

export TF_VAR_TIMESTAMP="$( date --rfc-3339=seconds )"

variable "TIMESTAMP" { default = "1900-01-01 00:00:00+02:00" }

provider "aws" {
  region = var.AWS_REGION
  default_tags {
    tags = {
      "tf:apply" = var.TIMESTAMP  
    }
  }
}

This works with Terraform v0.13.7

StackRef · 2021-10-18T15:27:19Z

Having this same issue with TF 1.0,9 when applying tags to aws_organizations_account -- only way around it is to comment out the default tags, apply, uncomment default tags, apply.

dmccaffery · 2021-10-21T11:23:41Z

We have also hit this issue in a slightly different form whereas a depends_on on the resource will cause a diff in tags vs tags_all at plan time even though all of the tags are statically defined. Works completely fine when dependencies are automatically determined; kinda weird.

JamesMcOrmond · 2021-11-05T20:47:57Z

still confirmed with Terraform 1.0.10 and aws provider 3.64.x..

if I have a dynamic (in my case a random id) as part of default_tags set in the provider configs, my apply run is very inconsistent.
its the same 'new element has appeared" style messages as above.

Jpk518 · 2023-03-30T18:55:17Z

Think this issue might be getting fixed in next major release of the provider #29842

glg-satish-tripathi · 2023-04-10T07:19:34Z

Hi there,
Another victim 👍
terraform version: v1.4.4
provider version : 4.62.0

resource "aws_subnet" "spacelift_public_subnet" {
  vpc_id                  = var.vpc_id
  count                   = length(var.spacelift_public_subnets_cidr)
  cidr_block              = element(var.spacelift_public_subnets_cidr, count.index)
  availability_zone_id    = element(var.availability_zone_ids, count.index)
  map_public_ip_on_launch = true
  tags = {
    Name = "${var.name}-${element(var.availability_zone_ids, count.index)}-public-subnet"
  }
}
resource "aws_security_group" "spacelift_sg" {
  description = "Security group to allow inbound/outbound from the VPC"
  vpc_id      = var.vpc_id

  ingress {
    from_port = 0
    to_port   = 0
    protocol  = "-1"
    # Primary vpc cidr in infrastructure-management account.
    cidr_blocks = [var.vpc_cidr]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "${var.name}"
  }
}

In some runs this fails.

Error: Provider produced inconsistent final plan
│
│ When expanding the plan for module.spacelift_networking.aws_subnet.spacelift_public_subnet[1] to include new values learned so far during apply, provider “registry.terraform.io/hashicorp/aws” produced an
│ invalid new value for .tags_all: new element “Name” has appeared.
│
│ This is a bug in the provider, which should be reported in the provider’s own issue tracker.

DoyleDev · 2023-04-18T18:25:07Z

another victim of this bug, please fix Hashicorp 😢

ofey404 · 2023-05-11T02:50:59Z

Hi, there.

A new victim appears.

Version:

Terraform v1.4.5
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v4.66.1

I use eks blueprints, but basically the problem lies on the managed node group.

module "eks_blueprints" {
  source = "github.com/aws-ia/terraform-aws-eks-blueprints?ref=v4.25.0"
  tags         = local.tags
}

Error output:

╷
│ Error: Provider produced inconsistent final plan
│
│ When expanding the plan for module.eks_testing.module.eks_blueprints.module.aws_eks_managed_node_groups["basic"].aws_eks_node_group.managed_ng to include new values learned so far during apply, provider        
│ "registry.terraform.io/hashicorp/aws" produced an invalid new value for .tags_all: new element "managed-by" has appeared.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵

rajmartha26 · 2023-05-18T14:35:22Z

one more victim.

@johnsonaj when you say it is merged that means this problem is fixed? what version of TF we need to use?

qa97 · 2023-05-23T15:44:33Z

another victim
Hashicorp, please help

│ Error: Provider produced inconsistent final plan
│
│ When expanding the plan for module.kafka.module.broker_security_group.aws_security_group.default[0] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for
│ .tags_all: new element "Stage" has appeared.
│
│ 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 module.eks_node_group.aws_launch_template.default[0] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for .tags_all: new element
│ "Attributes" has appeared.
│
│ 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 module.eks_node_group.aws_launch_template.default[0] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for .tags_all: new element
│ "Name" has appeared.
│
│ 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 module.eks_node_group.aws_launch_template.default[0] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for .tags_all: new element
│ "Namespace" has appeared.
│
│ 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 module.eks_node_group.aws_launch_template.default[0] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for .tags_all: new element
│ "Stage" has appeared.
│
│ 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 module.eks_node_group.aws_launch_template.default[0] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for .tags_all: new element
│ "k8s.io/cluster-autoscaler/enabled" has appeared.
│
│ 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 module.eks_node_group.aws_launch_template.default[0] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for .tags_all: new element
│ "k8s.io/cluster-autoscaler/witty-temp-test-cluster-cluster" has appeared.
│
│ 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 module.eks_node_group.aws_launch_template.default[0] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for .tags_all: new element
│ "kubernetes.io/cluster/witty-temp-test-cluster-cluster" has appeared.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

johnsonaj · 2023-05-24T15:07:40Z

@rajmartha26 we have done work to allow resource tags to be computed values. This update will be released in v5.0.0 of the provider.

It is still not possible to have computed values in the provider level default_tags block. This is due to limitations on how the provider is configured and how these default_tags are applied to resources downstream.

The following configuration will be possible in v5.0.0

provider "aws" {
  region = "us-west-2"
}

resource "aws_s3_bucket" "example" {
  bucket = "example-bucket"
  tags = {
    created_at = timestamp()
  }
}

However, the follow will still not compute correctly because default_tags must be known values

provider "aws" {
  region = "us-west-2"
  default_tags {
    tags = {
        created_at = timestamp()
    }
  }
}

resource "aws_s3_bucket" "example" {
  bucket = "example-bucket"
  tags     = {
    additional_tag = "value
  }
}

rajmartha26 · 2023-05-24T17:50:24Z

@johnsonaj something like below will be possible in v5.0.0 ?

provider "aws" {
  region = "us-west-2"
  default_tags {
    tags = {
        additional_tag = "value"
       additional_tag = "value-2"
        
    }
  }
}

resource "aws_s3_bucket" "example" {
  bucket = "example-bucket"
  tags     = {
    created_at = timestamp()
  }
}

johnsonaj · 2023-05-24T18:32:45Z

@johnsonaj something like below will be possible in v5.0.0 ?

provider "aws" {
  region = "us-west-2"
  default_tags {
    tags = {
        additional_tag = "value"
       additional_tag = "value-2"
        
    }
  }
}

resource "aws_s3_bucket" "example" {
  bucket = "example-bucket"
  tags     = {
    created_at = timestamp()
  }
}

@rajmartha26 yes, that will be possible when v5 is released. The timestamp() function will change values on every run since it includes time, so this may not be the best example, however computed values will be accepted

rajmartha26 · 2023-05-24T18:41:40Z

@johnsonaj The timestamp() function will change values on every run since it includes time, so we add that in ignore_changes,

Any time line when the v5 will release?

DarrenBishop · 2023-05-25T15:18:34Z

Hi @johnsonaj I am not sure what constitutes a 'computed value'; does it include vars passed in via TF_VAR_ or -var-file blah.tfvars?

I am standing up EKS and deploying a bunch of Helm charts (helm_release) - in a sense for multi-tenancy, hence the vars going into default-tags - and this issue causes a mess; the plan from a clean slate has 94+ resources, but the true number is greater.

github-actions · 2023-05-25T17:27:33Z

This functionality has been released in v5.0.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

rmetzler · 2023-06-07T12:27:07Z

I don't think this is fixed in v5.1.0 of Terraform AWS Provider

morremeyer · 2023-06-07T13:08:20Z

@rmetzler Can you please provide more information why you think that? Ideally a minimal reproduction so others can understand why you think that?

nazarewk · 2023-06-20T13:21:59Z

I'm also observing the issue today, but I don't know how to reproduce

github-actions · 2023-07-21T02:13:01Z

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 bot added needs-triage Waiting for first response or review from a maintainer. bug Addresses a defect in current functionality. service/ec2 Issues and PRs that pertain to the ec2 service. labels May 30, 2021

anGie44 self-assigned this Jun 1, 2021

anGie44 removed the needs-triage Waiting for first response or review from a maintainer. label Jun 1, 2021

ewbankkit mentioned this issue Jun 7, 2021

r/aws_sqs_queue: support high-throughput FIFO queues #19639

Merged

jasonumiker mentioned this issue Sep 22, 2021

Error when deploying related to S3 Tags aws-samples/amazon-ecs-fullstack-app-terraform#5

Closed

sanderginn mentioned this issue Mar 4, 2023

Refactor: optionally randomize resource names sourcegraph/terraform-aws-executors#73

Merged

This was referenced Mar 6, 2023

Provider produced inconsistent final plan hashicorp/terraform-provider-random#380

Closed

Could we generate random results at plan time rather than apply time? hashicorp/terraform-provider-random#121

Open

scheleaap mentioned this issue Mar 27, 2023

[Bug]: When expanding the plan for aws_ecs_service.qa-ecs-service [...] provider aws produced an invalid new value for .triggers["redeployment"]: was cty.StringVal("2022-11-28T16:50:44Z"), but now │ cty.StringVal("2022-11-28T18:08:03Z"). #28070

Open

roblevy mentioned this issue Mar 27, 2023

invalid new value for .tags_all: new element "<tagname>" has appeared. dare-global/terraform-aws-rds-aurora#4

Closed

ewbankkit mentioned this issue Apr 16, 2023

[Bug]: Inconsistent final plan with tags_all when using apply time values as resource tags #30756

Closed

johnsonaj mentioned this issue Apr 26, 2023

tags: duplicate and computed tags on framework #30973

Merged

bion mentioned this issue May 3, 2023

Fix terraform deployment bugs civiform/cloud-deploy-infra#161

Closed

johnsonaj added this to the v5.0.0 milestone May 11, 2023

johnsonaj mentioned this issue May 11, 2023

default tags: add changelog and upgrade guide entry #31343

Merged

johnsonaj closed this as completed May 24, 2023

This was referenced May 31, 2023

revert default tags hashicorp/terraform-aws-terraform-enterprise#292

Merged

update to v5 AWS provider hashicorp/terraform-aws-terraform-enterprise#293

Open

github-actions bot locked as resolved and limited conversation to collaborators Jul 21, 2023

Provider produced inconsistent final plan / an invalid new value for .tags_all #19583

Provider produced inconsistent final plan / an invalid new value for .tags_all #19583

Comments

chgasparoto commented May 30, 2021 • edited by anGie44 Loading

Community Note

Terraform CLI and Terraform AWS Provider Version

Affected Resource(s)

Terraform Configuration Files

Debug Output

Panic Output

Expected Behavior

Actual Behavior

Steps to Reproduce

Important Factoids

References

anGie44 commented Jun 1, 2021

matiu2 commented Jun 2, 2021

matiu2 commented Jun 2, 2021

anGie44 commented Jun 3, 2021

ashraf133 commented Jun 7, 2021 • edited by anGie44 Loading

Marinaburkhardt commented Jun 9, 2021

Used versions

Expected Behavior

Actual Behavior

Code snippet

Plan output

Error output (during apply)

anGie44 commented Jun 9, 2021 • edited Loading

anniehedgpeth commented Jun 11, 2021 • edited Loading

Marinaburkhardt commented Jun 14, 2021

Apply output:

sorengraungaard commented Jun 14, 2021

share-me commented Jun 22, 2021

rtoma commented Jun 28, 2021

tuxtek commented Jul 6, 2021

sneha43sweety commented Jul 9, 2021

jgeurts commented Jul 21, 2021 • edited Loading

sneha43sweety commented Jul 21, 2021 • edited Loading

sarangk39 commented Jul 21, 2021 • edited Loading

Our current terraform configuration looks like this -

Code output -

When we run the terraform files, getting below error -

Code output (when tables are deleted manually) -

inhumantsar commented Aug 5, 2021

cmd-werner-diers commented Aug 10, 2021

kihom-77 commented Aug 11, 2021 • edited Loading

StackRef commented Oct 18, 2021

dmccaffery commented Oct 21, 2021

JamesMcOrmond commented Nov 5, 2021

Jpk518 commented Mar 30, 2023

glg-satish-tripathi commented Apr 10, 2023 • edited Loading

DoyleDev commented Apr 18, 2023

ofey404 commented May 11, 2023

rajmartha26 commented May 18, 2023

qa97 commented May 23, 2023

johnsonaj commented May 24, 2023 • edited Loading

rajmartha26 commented May 24, 2023 • edited Loading

johnsonaj commented May 24, 2023

rajmartha26 commented May 24, 2023 • edited Loading

DarrenBishop commented May 25, 2023

github-actions bot commented May 25, 2023

rmetzler commented Jun 7, 2023

morremeyer commented Jun 7, 2023

nazarewk commented Jun 20, 2023 • edited Loading

github-actions bot commented Jul 21, 2023

chgasparoto commented May 30, 2021 •

edited by anGie44

Loading

ashraf133 commented Jun 7, 2021 •

edited by anGie44

Loading

anGie44 commented Jun 9, 2021 •

edited

Loading

anniehedgpeth commented Jun 11, 2021 •

edited

Loading

jgeurts commented Jul 21, 2021 •

edited

Loading

sneha43sweety commented Jul 21, 2021 •

edited

Loading

sarangk39 commented Jul 21, 2021 •

edited

Loading

kihom-77 commented Aug 11, 2021 •

edited

Loading

glg-satish-tripathi commented Apr 10, 2023 •

edited

Loading

johnsonaj commented May 24, 2023 •

edited

Loading

rajmartha26 commented May 24, 2023 •

edited

Loading

rajmartha26 commented May 24, 2023 •

edited

Loading

nazarewk commented Jun 20, 2023 •

edited

Loading