cloudposse/terraform-aws-vpc 1.1.0

v1.1.0 IPv6 & IPAM support, minor breaking change

on GitHub

what

• Adds support for IPv6 configuration
• Adds preliminary support for IP Address Manager (IPAM)
• Updates framework to current

why

• Support new features by request

migration notes

These changes should be backward compatible. However, 3 variables were deprecated and replaced, and use of the new variables is encouraged.

ipv6_enabled deprecated in favor of assign_generated_ipv6_cidr_block

In PR #99 released in version v0.28.0, we deprecated assign_generated_ipv6_cidr_block in favor of ipv6_enabled as part of a more general renaming of inputs to follow Cloud Posse's convention of naming boolean flags with _enabled at the end. However, now that we have IPAM, the name ipv6_enabled is misleading: it only means assign_generated_ipv6_cidr_block and you have to set that to false in order to assign an IPv6 address from IPAM. We do not want require you to set ipv6_enabled = false in order to use IPv6 IPAM, so we are reversing course on this variable, deprecating ipv6_enabled and reviving assign_generated_ipv6_cidr_block.

cidr_block deprecated in favor of ipv4_primary_cidr_block

Now that a VPC can have multiple IPv4 CIDR blocks along with multiple IPv6 CIDR blocks, the name cidr_block is just too vague. Use ipv4_primary_cidr_block instead to set the primary IPv4 CIDR block for the VPC.

additional_cidr_blocks deprecated in favor of ipv4_additional_cidr_block_associations

As with cidr_block, additional_cidr_blocks is now too vague given that the module supports both IPv4 and IPv6 CIDR blocks. Also, you now have the option of having these CIDR blocks allocated by IPAM rather than being specified directly, requiring additional input parameters. So we created the new ipv4_additional_cidr_block_associations and the parallel ipv6_additional_cidr_block_associations to replace additional_cidr_blocks (which, while deprecated, remains supported for now).

Note that the new variables take maps of configurations rather than lists of configurations. This is because each configuration is deployed as a separate Terraform resource, and the resources are not easily deleted and recreated. If you supply a list and then later remove the first element of the list, Terraform will deleted and recreate all the resources because Terraform tracks them by their list index and does not detect that they have simply moved. It sees that configuration 1 has changed (it is now what used to be configuration 2) so it deletes the old 1 and creates the old 2 as the new 1. This annoying at best, and with CIDR blocks being deleted and recreated it will likely fail at worst.

By providing the configurations as maps, you give each configuration a stable label, so that when you make a change, only the affected configuration changes. Removing a configuration does not affect the other configurations. The labels you assign are arbitrary and for your own benefit; the only requirement is that they be known at "plan time", meaning they cannot be generated by the Terraform code itself.

notes

Due to the difficulty of configuring and testing the AWS VPC IP Address Manager, this feature has not been tested and support for it should be considered preliminary. Please report issues as you discover them.

Some inputs have been deprecated. New inputs typically take a map rather than a list so that we can use for_each (for stability as the set of inputs changes) without relying on the values in the list (which can cause Terraform to complain that the results depend on values not available at "plan" time).

Supersedes and closes #103

what

• Add ipv4_ipam_pool_id & ipv4_netmask_length variables
• Update cidr_block with default value of null
• Variables cidr_block is mutually exclusive to using ipv4_ipam_pool_id and ipv4_netmask_length

why

• In order to support assigning the cidr_block auto-assignment for a VPC provided from an AWS VPC IPAM pool