terraform-ibm-modules/terraform-ibm-landing-zone-vpc

Conflicting address prefix and subnets for multi-regional deployments

smathews opened this issue · 2 comments

Affected modules

https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone-vpc/

Terraform CLI and Terraform provider versions

  • Terraform version: v1.3.8
  • Provider version: 1.49.0

Expected behavior

Non-conflicting CIDRs between regions. Please use VPC defaults. Ideally use the VPC defaults without creating new address prefixes. The work-around is creating a local map with address prefixes for each region and defining the subnets manually.

This causes a few issues:

  • Impossible to use transit gateway with defaults
  • Default address prefixes are not used and not cleaned up
  • Kludge code to workaround (for each usage):
  address_prefixes            = {
    zone-1  = ["10.40.10.0/24"]
    zone-2  = ["10.50.10.0/24"]
    zone-3  = ["10.60.10.0/24"]
  }
  subnets                     = {
    zone-1  = [{
      acl_name  = "vpc-acl"
      name      = "zone-1"
      cidr      = "10.40.10.0/24"
    }]
    zone-2  = [{
      acl_name  = "vpc-acl"
      name      = "zone-2"
      cidr      = "10.50.10.0/24"
    }]
    zone-3  = [{
      acl_name  = "vpc-acl"
      name      = "zone-3"
      cidr      = "10.60.10.0/24"
    }]
  }

See: https://github.ibm.com/mathewss/SLZ-Demo/blob/main/main.tf

Actual behavior

Address prefixes conflict between regions, which could cause long term issues for slz adopters as they scale.

Steps to reproduce (including links and screen captures)

Create an SLZ with defaults in 2 or more regions.

Anything else

Unintuitive use of vpc-acl for the network_acl index. Without looking at the code, its very difficult to know the name that should be specified for acl_name when specifying the subnets object.

@smathews looking at your SLZ Demo repo that was linked I see that the demo is making two separate calls to the module for setting up the environments in different regions, due to these calls being made to the same module they will always have the same defaults and will not have knowledge of the other calls to adjust the default values used in the module. The method of overriding these default values in your multi-region example is the appropriate way to handle deploying multiple VPCs with non-conflicting subnets.

@MatthewLemmond It's linked to the same module, because it's the SLZ module. If you made the address prefixes aware of the region, you could avoid this. You could create a mapping of default addresses by the region, instead of hardcoding it.

Also, how is a user to know they need to use vpc-acl as the acl_name when defining the subnets?