Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unchanged aws_vpc resource recreated due to assign_generated_ipv6_cidr_block #13035

Closed
dominics opened this issue Mar 24, 2017 · 3 comments · Fixed by #13041
Closed

Unchanged aws_vpc resource recreated due to assign_generated_ipv6_cidr_block #13035

dominics opened this issue Mar 24, 2017 · 3 comments · Fixed by #13041

Comments

@dominics
Copy link

dominics commented Mar 24, 2017

I've noticed a regression on master (which I'm running to get the fix for an unrelated issue)

Terraform Version

v0.9.2-dev - rough bisect, strongly suspect any commit after bed23ff

Affected Resource(s)

  • aws_vpc

Terraform Configuration Files

resource "aws_vpc" "vpc" {
  cidr_block           = "172.20.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags {
    Name = "default"
  }

  lifecycle {
    create_before_destroy = true
  }
}

Expected Behavior

No changes on terraform plan after 0.9.2-dev/master upgrade

Actual Behavior

Plan attempts to force-recreate the VPC, showing a "" => "false" difference on assign_generated_ipv6_cidr_block:

-/+ module.vpc.aws_vpc.vpc
    assign_generated_ipv6_cidr_block: "" => "false" (forces new resource)
    cidr_block:                       "172.20.0.0/16" => "172.20.0.0/16"
    default_network_acl_id:           "acl-abcdef01" => "<computed>"
    default_route_table_id:           "rtb-abcdef01" => "<computed>"
    default_security_group_id:        "sg-abcdef01" => "<computed>"
    dhcp_options_id:                  "dopt-abcdef01" => "<computed>"
    enable_classiclink:               "false" => "<computed>"
    enable_dns_hostnames:             "true" => "true"
    enable_dns_support:               "true" => "true"
    instance_tenancy:                 "default" => "<computed>"
    ipv6_association_id:              "" => "<computed>"
    ipv6_cidr_block:                  "" => "<computed>"
    main_route_table_id:              "rtb-abcdef01" => "<computed>"
    tags.%:                           "1" => "1"
    tags.Name:                        "default" => "default"

I added assign_generated_ipv6_cidr_block = false explicitly, to attempt to work around the problem, and it worked at least some of the time. But I still (in some environments?!) saw plans that attempted to recreate the VPC.

Steps to Reproduce

  • Create this resource using a stable version, like 0.9.1
  • Upgrade to latest master version
  • terraform plan

References

@stack72
Copy link
Contributor

stack72 commented Mar 24, 2017

Hi @dominics

You are indeed correct - I am sorry for this issue - I am opening a PR right now that will migrate the state for you and take care of it

Paul

stack72 added a commit that referenced this issue Mar 24, 2017
Fixes: #13035

It was pointed out in the issue that the addition of a new parameter
with a default value AND a ForceNew: true is causing Terraform to try
and recreate the VPC

This PR migrates the state to add the default value of false for `assign_generated_ipv6_cidr_block`

```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAWSVpcMigrateState'            130 ↵ ✚
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/03/24 12:43:00 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAWSVpcMigrateState -timeout 120m
=== RUN   TestAWSVpcMigrateState
2017/03/24 12:43:56 [INFO] Found AWS VPC State v0; migrating to v1
--- PASS: TestAWSVpcMigrateState (0.00s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/aws	0.025s
```
stack72 added a commit that referenced this issue Mar 24, 2017
Fixes: #13035

It was pointed out in the issue that the addition of a new parameter
with a default value AND a ForceNew: true is causing Terraform to try
and recreate the VPC

This PR migrates the state to add the default value of false for `assign_generated_ipv6_cidr_block`

```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAWSVpcMigrateState'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/03/24 12:51:41 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAWSVpcMigrateState -timeout 120m
=== RUN   TestAWSVpcMigrateState
2017/03/24 12:52:26 [INFO] Found AWS VPC State v0; migrating to v1
2017/03/24 12:52:26 [DEBUG] Attributes before migration: map[string]string{"assign_generated_ipv6_cidr_block":"true"}
2017/03/24 12:52:26 [DEBUG] Attributes after migration: map[string]string{"assign_generated_ipv6_cidr_block":"false"}
2017/03/24 12:52:26 [INFO] Found AWS VPC State v0; migrating to v1
2017/03/24 12:52:26 [DEBUG] Attributes before migration: map[string]string{}
2017/03/24 12:52:26 [DEBUG] Attributes after migration: map[string]string{"assign_generated_ipv6_cidr_block":"false"}
--- PASS: TestAWSVpcMigrateState (0.00s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/aws	0.024s
```
stack72 added a commit that referenced this issue Mar 24, 2017
Fixes: #13035

It was pointed out in the issue that the addition of a new parameter
with a default value AND a ForceNew: true is causing Terraform to try
and recreate the VPC

This PR migrates the state to add the default value of false for `assign_generated_ipv6_cidr_block`

```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAWSVpcMigrateState'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/03/24 12:51:41 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAWSVpcMigrateState -timeout 120m
=== RUN   TestAWSVpcMigrateState
2017/03/24 12:52:26 [INFO] Found AWS VPC State v0; migrating to v1
2017/03/24 12:52:26 [DEBUG] Attributes before migration: map[string]string{"assign_generated_ipv6_cidr_block":"true"}
2017/03/24 12:52:26 [DEBUG] Attributes after migration: map[string]string{"assign_generated_ipv6_cidr_block":"false"}
2017/03/24 12:52:26 [INFO] Found AWS VPC State v0; migrating to v1
2017/03/24 12:52:26 [DEBUG] Attributes before migration: map[string]string{}
2017/03/24 12:52:26 [DEBUG] Attributes after migration: map[string]string{"assign_generated_ipv6_cidr_block":"false"}
--- PASS: TestAWSVpcMigrateState (0.00s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/aws	0.024s
```
@brianwallace
Copy link

brianwallace commented Apr 3, 2017

Pretty sure I am still seeing this behavior in terraform v0.9.2:

The following snippet is from a terraform plan on pre-0.9.2 configuration:

-/+ module.template.aws_vpc.main
    assign_generated_ipv6_cidr_block: "" => "false" (forces new resource)
    cidr_block:                       "10.0.0.0/16" => "10.0.0.0/16"
    default_network_acl_id:           "acl-8f9602ea" => "<computed>"
    default_route_table_id:           "rtb-5b16843e" => "<computed>"
    default_security_group_id:        "sg-0e45a36a" => "<computed>"
    dhcp_options_id:                  "dopt-15776477" => "<computed>"
    enable_classiclink:               "false" => "<computed>"
    enable_dns_hostnames:             "true" => "true"
    enable_dns_support:               "true" => "true"
    instance_tenancy:                 "default" => "<computed>"
    ipv6_association_id:              "" => "<computed>"
    ipv6_cidr_block:                  "" => "<computed>"
    main_route_table_id:              "rtb-5b16843e" => "<computed>"
    tags.%:                           "3" => "3"
    tags.Environment:                 "staging" => "staging"
    tags.KubernetesCluster:           "midgard" => "midgard"
    tags.Name:                        "staging" => "staging"

I attempted to add assign_generated_ipv6_cidr_block = false to the vpc resource, but it did not seem to make a difference.

UPDATE 4/5/2017: I think this is the same issue identified and fixed in Issue #13197. Looks like it will be in v0.9.3.

@ghost
Copy link

ghost commented Apr 14, 2020

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.

@ghost ghost locked and limited conversation to collaborators Apr 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants