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

provider/aws: Allow AWS Subnet to change IPv6 CIDR Block without ForceNew #13909

Merged
merged 1 commit into from
Apr 24, 2017

Conversation

stack72
Copy link
Contributor

@stack72 stack72 commented Apr 24, 2017

Fixes: #13588

It was pointed out in #13588 that we don't need to ForceNew on a change
of IPv6 CIDR block. The logic I decided to implement here was to
disassociate then associate. We should only be able to be associated to
1 IPv6 CIDR block at once. This feels like a risky move. We can
disassociate and then error on the associate. This would leave us in a
situation where we have no IPv6 CIDR block associated

The alternative here would be that the failure of association, triggers
a reassociation with the old IPv6 CIDR block

I added a test to make sure that the subnet Ids don't change as the ipv6
block changes. Before removing the ForceNew from the ipv6_cidr_block,
the test results in the following:

=== RUN   TestAccAWSSubnet_ipv6
--- FAIL: TestAccAWSSubnet_ipv6 (92.09s)
	resource_aws_subnet_test.go:105: Expected SubnetIDs not to change, but both got before: subnet-0d2b6a6a and after: subnet-742c6d13

After the removal of ForceNew, the test result looks as follows:

=== RUN   TestAccAWSSubnet_ipv6
--- PASS: TestAccAWSSubnet_ipv6 (188.34s)
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSSubnet_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/04/24 21:26:36 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSSubnet_ -timeout 120m
=== RUN   TestAccAWSSubnet_importBasic
--- PASS: TestAccAWSSubnet_importBasic (85.63s)
=== RUN   TestAccAWSSubnet_basic
--- PASS: TestAccAWSSubnet_basic (80.28s)
=== RUN   TestAccAWSSubnet_ipv6
--- PASS: TestAccAWSSubnet_ipv6 (188.34s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/aws	354.283s

…eNew

Fixes: #13588

It was pointed out in #13588 that we don't need to ForceNew on a change
of IPv6 CIDR block. The logic I decided to implement here was to
disassociate then associate. We should only be able to be associated to
1 IPv6 CIDR block at once. This feels like a risky move. We can
disassociate and then error on the associate. This would leave us in a
situation where we have no IPv6 CIDR block associated

The alternative here would be that the failure of association, triggers
a reassociation with the old IPv6 CIDR block

I added a test to make sure that the subnet Ids don't change as the ipv6
block changes. Before removing the ForceNew from the ipv6_cidr_block,
the test results in the following:

```
=== RUN   TestAccAWSSubnet_ipv6
--- FAIL: TestAccAWSSubnet_ipv6 (92.09s)
	resource_aws_subnet_test.go:105: Expected SubnetIDs not to change, but both got before: subnet-0d2b6a6a and after: subnet-742c6d13
```

After the removal of ForceNew, the test result looks as follows:

```
=== RUN   TestAccAWSSubnet_ipv6
--- PASS: TestAccAWSSubnet_ipv6 (188.34s)
```

```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSSubnet_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/04/24 21:26:36 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSSubnet_ -timeout 120m
=== RUN   TestAccAWSSubnet_importBasic
--- PASS: TestAccAWSSubnet_importBasic (85.63s)
=== RUN   TestAccAWSSubnet_basic
--- PASS: TestAccAWSSubnet_basic (80.28s)
=== RUN   TestAccAWSSubnet_ipv6
--- PASS: TestAccAWSSubnet_ipv6 (188.34s)
PASS
ok  	github.com/hashicorp/terraform/builtin/providers/aws	354.283s
```
@stack72 stack72 changed the title provider/aws: Allow AWS Subnet to change IPv6 CIDR Block without Forc… provider/aws: Allow AWS Subnet to change IPv6 CIDR Block without ForceNew Apr 24, 2017
Copy link
Contributor

@grubernaut grubernaut left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@stack72 stack72 merged commit 1eeb3c4 into master Apr 24, 2017
@stack72 stack72 deleted the b-aws-subnet-ipv6-change-cidr-block branch April 24, 2017 20:39
@ghost
Copy link

ghost commented Apr 13, 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 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unnecessary vpc/subnet recreation planned when modifying ipv6 settings
2 participants