You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Community Note
Description
Terraform Resource
ibm_is_vpc
will use the argumentaddress_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 Sourceibm_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.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 cascadingforces 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
Current workaround to ensure Terraform predictability
The text was updated successfully, but these errors were encountered: