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

ibm_is_vpc: address prefix planning predictability #5919

Open
sean-freeman opened this issue Jan 15, 2025 · 0 comments
Open

ibm_is_vpc: address prefix planning predictability #5919

sean-freeman opened this issue Jan 15, 2025 · 0 comments
Labels
enhancement service/VPC Infrastructure Issues related to the VPC Infrastructure

Comments

@sean-freeman
Copy link

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Terraform Resource ibm_is_vpc will use the argument address_prefix_management = "auto" automatically, unless overriden. This instructs the Create VPC API to use the Default Address Prefixes (defined by IBM Cloud) for creating the VPC.

IBM Cloud Infrastructure services use a static non-overlapping range per IBM Cloud Region, thereby any VPC created with automatic prefix management will be selected from a known list of Default Address Prefixes (which have not been altered since 2018 with VPC functionality release, and will not be altered).

However, Terraform is unaware of these static default values and they are not directly returned to the ibm_is_vpc resource object by the API. This means an end-user would need to create a Data Source ibm_is_vpc_address_prefix/ibm_is_vpc_address_prefixes, which introduces a planning problem that can cause significant issues in a Terraform Template (particularly those that elastically create VPCs in multiple IBM Cloud Regions).

A workaround to this, is to set address_prefix_management = "manual" and provide a Terraform Variable Map of the Default Address Prefixes for each IBM Cloud Region and their Availability Zones. This is additional unnecessary code, though.

To assist Terraform end-users, I would suggest a hard code of these Default Address Prefixes into the Terraform Provider.

This will mean Terraform is fully aware of the static Default Address Prefixes, and not require the end-user to implement a Terraform Data Source to use the value - which in turn means any amend/create/remove of a VPC, will not cause the Terraform Data Source to show (known after apply) and lead to cascading forces replacement for all Terraform Resources that rely on the Terraform Data Source.

This will create stability/predictability for the Terraform logic engine, and avoid issues in any re-run of Terraform.

New or Affected Resource(s)

  • ibm_is_vpc

Potential Terraform Plan/Apply stdout

# ibm_is_vpc.vpc-us-south will be created
+ resource "ibm_is_vpc" "vpc-us-south" {
    + access_tags                 = (known after apply)
    + address_prefix_management   = "auto"
    + default_address_prefixes    = {
      + us-south-1 = "10.240.0.0/18"
      + us-south-2 = "10.240.64.0/18"
      + us-south-3 = "10.240.128.0/18"
    ....
  }

Current workaround to ensure Terraform predictability

resource "ibm_is_vpc" "vpc-us-south" {
  resource_group = ""
  name           = ""
  address_prefix_management = "manual"
}

resource "ibm_is_vpc_address_prefix" "vpc-prefix-us-south" {
  for_each       = var.map_ibmcloud_vpc_address_prefix_defaults["us-south"]
  name           = ""
  vpc            = ibm_is_vpc.vpc-us-south.id
  zone           = each.key
  cidr           = each.value
  is_default     = true
}
variable "map_ibmcloud_vpc_address_prefix_defaults" {
  description = "Map of IBM Cloud Infrastructure services VPC Address Prefix defauls in each IBM Cloud Region"
  type = map(any)
  default = {
    au-syd = {
      au-syd-1 = "10.245.0.0/18"
      au-syd-2 = "10.245.64.0/18"
      au-syd-3 = "10.245.128.0/18"
    }
    br-sao = {
      br-sao-1 = "10.250.0.0/18"
      br-sao-2 = "10.250.64.0/18"
      br-sao-3 = "10.250.128.0/18"
    }
    ca-tor = {
      ca-tor-1 = "10.249.0.0/18"
      ca-tor-2 = "10.249.64.0/18"
      ca-tor-3 = "10.249.128.0/18"
    }
    eu-de = {
      eu-de-1 = "10.243.0.0/18"
      eu-de-2 = "10.243.64.0/18"
      eu-de-3 = "10.243.128.0/18"
    }
    eu-es = {
      eu-es-1 = "10.251.0.0/18"
      eu-es-2 = "10.251.64.0/18"
      eu-es-3 = "10.251.128.0/18"
    }
    eu-gb = {
      eu-gb-1 = "10.242.0.0/18"
      eu-gb-2 = "10.242.64.0/18"
      eu-gb-3 = "10.242.128.0/18"
    }
    jp-osa = {
      jp-osa-1 = "10.248.0.0/18"
      jp-osa-2 = "10.248.64.0/18"
      jp-osa-3 = "10.248.128.0/18"
    }
    jp-tok = {
      jp-tok-1 = "10.244.0.0/18"
      jp-tok-2 = "10.244.64.0/18"
      jp-tok-3 = "10.244.128.0/18"
    }
    us-east = {
      us-east-1 = "10.241.0.0/18"
      us-east-2 = "10.241.64.0/18"
      us-east-3 = "10.241.128.0/18"
    }
    us-south = {
      us-south-1 = "10.240.0.0/18"
      us-south-2 = "10.240.64.0/18"
      us-south-3 = "10.240.128.0/18"
    }
  }
}
@github-actions github-actions bot added the service/VPC Infrastructure Issues related to the VPC Infrastructure label Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement service/VPC Infrastructure Issues related to the VPC Infrastructure
Projects
None yet
Development

No branches or pull requests

1 participant