provider/aws: Allow AWS Subnet to change IPv6 CIDR Block without ForceNew #13909
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
After the removal of ForceNew, the test result looks as follows: