/run pipeline

/run pipeline

/run pipeline

Testing logs:

I tested the script using the following steps:

1. Ran terraform apply on the main branch with the prefix set to testvpc.
2. Updated the prefix to testvpc1 and ran terraform plan on the same infrastructure. The plan indicated that some resources would be destroyed.
3. Switched to my branch and executed the migration script, which updated the existing infrastructure to align with the latest changes.
4. Ran terraform apply again with the new prefix (testvpc1). This time, no resources were marked for destruction.

VPC keys migration script logs.txt

Before

• Resource keys were indirectly tied to var.prefix
• Changing prefix → Terraform saw:
  - old keys removed
  - new keys added
• Result: destroy & recreate resources

After

• for_each uses a map keyed by resource_name (e.g. 1-subnet-a)
• prefix is used only in the actual IBM Cloud resource name, not the Terraform key
• Changing prefix now causes:
  - in-place name update
  - or no change at all
• Terraform state keys remain unchanged → no destroy

Migration

• A migration script renames existing Terraform state entries:
  <old-prefix>-vpc-subnet-a → 1-subnet-a
• This updates state without touching real infrastructure
• After migration, plans become clean even when prefix changes

/run pipeline

/run pipeline

/run pipeline

/run pipeline

Skipping the upgrade test because this change updates the Terraform keys used for subnets and address prefixes . it will not find the existing resources. Upgrade will fail.

/run pipeline

/run pipeline

@Khuzaima05 Hang on - we can't just skip the upgrade test. Isn't it flagging a valid breaking change? How are we going to handle this. Do we have migration?

@Khuzaima05 The scripts you added are for module consumers, but what about the DA? We have several DAs that use this module. We need to full understand the impact here. DA users are not going to know about the scripts you added. Plus we have several other external consumes like PowerVS, HPC etc etc. We need to find a clean way to do this.
In the past we had to use a pre-deploy ansible script for DAs. but its a lot of effort. I want to fully understand why we are making this breaking change after many years of using this code. Please add to the deep dive here so we can discuss.

Please also be aware that if this PR does proceed as a major version update, the VPN code needs to be removed from it since in #1041 we say it will be removed in v9 of the module

@Khuzaima05 The scripts you added are for module consumers, but what about the DA? We have several DAs that use this module. We need to full understand the impact here. DA users are not going to know about the scripts you added. Plus we have several other external consumes like PowerVS, HPC etc etc. We need to find a clean way to do this. In the past we had to use a pre-deploy ansible script for DAs. but its a lot of effort. I want to fully understand why we are making this breaking change after many years of using this code. Please add to the deep dive here so we can discuss.

@ocofaigh , sure I will add this topic in tomorrow’s deep dive.

As discussed in the deep dive, fixing this issue now would take a lot of effort and coordination because the VPC module is used by many DAs and other consumers. The impact of a breaking change would be too large.

Next steps:

• Find all repositories and DAs that use the VPC module and make sure this limitation is clearly mentioned.

• Clearly document this limitation in the prefix variable description so users know what to expect.

Closing this PR, as per deep dive discussion.