v4.4.0

4.4.0 (2024-11-28)

Features

• In this release, you can have more than 1 vsi per subnet when using secondary VNIs.

UPGRADE NOTES: When updating from v4.3.x to this version, if you have a secondary VNI and floating IPs for the secondary VNI enabled enabled, these resources will be recreated. There will be no effect on the VSI. In case, you need to prevent recreation of the secondary VNI and floating IPs associated with the secondary VNI, use the following terraform move commands based on the environment you are running the terraform module.
Terraform CLI:

terraform state mv 'module.<module-name>.ibm_is_virtual_network_interface.secondary_vni["<region>-1"]' 'module.<module-name>.ibm_is_virtual_network_interface.secondary_vni["<zone-1-subnet-name>-0"]'
terraform state mv 'module.<module-name>.ibm_is_virtual_network_interface.secondary_vni["<region>-2"]' 'module.<module-name>.ibm_is_virtual_network_interface.secondary_vni["<zone-2-subnet-name>-0"]'
terraform state mv 'module.<module-name>.ibm_is_virtual_network_interface.secondary_vni["<region>-3"]' 'module.<module-name>.ibm_is_virtual_network_interface.secondary_vni["<zone-3-subnet-name>-0"]'
terraform state mv 'module.<module-name>.ibm_is_floating_ip.vni_secondary_fip["<zone-1-subnet-name>"]' 'module.<module-name>.ibm_is_floating_ip.vni_secondary_fip["<zone-1-subnet-name>-0"]'
terraform state mv 'module.<module-name>.ibm_is_floating_ip.vni_secondary_fip["<zone-2-subnet-name>"]' 'module.<module-name>.ibm_is_floating_ip.vni_secondary_fip["<zone-2-subnet-name>-0"]'
terraform state mv 'module.<module-name>.ibm_is_floating_ip.vni_secondary_fip["<zone-3-subnet-name>"]' 'module.<module-name>.ibm_is_floating_ip.vni_secondary_fip["<zone-3-subnet-name>-0"]'

Schematics:

ibmcloud schematics workspace state mv --id <WORKSPACE_ID> --source 'module.<module-name>.ibm_is_virtual_network_interface.secondary_vni["us-south-1"]' --destination 'module.<module-name>.ibm_is_virtual_network_interface.secondary_vni["<zone-1-subnet-name>-0"]'
ibmcloud schematics workspace state mv --id <WORKSPACE_ID> --source 'module.<module-name>.ibm_is_virtual_network_interface.secondary_vni["us-south-2"]' --destination 'module.<module-name>.ibm_is_virtual_network_interface.secondary_vni["<zone-2-subnet-name>-0"]'
ibmcloud schematics workspace state mv --id <WORKSPACE_ID> --source 'module.<module-name>.ibm_is_virtual_network_interface.secondary_vni["us-south-3"]' --destination 'module.<module-name>.ibm_is_virtual_network_interface.secondary_vni["<zone-3-subnet-name>-0"]'
ibmcloud schematics workspace state mv --id <WORKSPACE_ID> --source 'module.<module-name>.ibm_is_floating_ip.vni_secondary_fip["<zone-1-subnet-name>"]' --destination 'module.<module-name>.ibm_is_floating_ip.vni_secondary_fip["<zone-1-subnet-name>-0"]'
ibmcloud schematics workspace state mv --id <WORKSPACE_ID> --source 'module.<module-name>.ibm_is_floating_ip.vni_secondary_fip["<zone-2-subnet-name>"]' --destination 'module.<module-name>.ibm_is_floating_ip.vni_secondary_fip["<zone-2-subnet-name>-0"]'
ibmcloud schematics workspace state mv --id <WORKSPACE_ID> --source 'module.<module-name>.ibm_is_floating_ip.vni_secondary_fip["<zone-3-subnet-name>"]' --destination 'module.<module-name>.ibm_is_floating_ip.vni_secondary_fip["<zone-3-subnet-name>-0"]'

(#753) (5e39a48)

v4.3.1

4.3.1 (2024-11-19)

Bug Fixes

• primary Virtual Network Interface will be named after the VSI it is associated with. This will result in a non disruptive update in place is upgrading from a previous version (#751) (c45ceff)

v4.3.0

4.3.0 (2024-11-11)

Features

• add support for Virtual Network Interface
  - The module now creates VSI using the next gen virtual network interface by default, these VNIs are created independent of the VSIs.

UPGRADE NOTES: When upgrading from a previous version, VSIs may be destroyed and recreated. To prevent re-creation or to use the legacy network interface, set var.use_legacy_network_interface to true. (#737) (46cd958)

v4.2.0

4.2.0 (2024-09-18)

Features

• This module now includes a boolean variable, use_boot_volume_key_as_default, which determines the default encryption key used for volumes. If use_boot_volume_key_as_default is set to true, the boot volume key (boot_volume_encryption_key) will be used as the default. Otherwise, if kms_encryption_enabled is true, the specified volume.encryption_key will be used.

UPGRADE NOTES: In previous versions, there was a possibility that your volume was encrypted with the boot volume key instead of the provided volume.encryption_key.
To avoid any unintentional destruction of volumes during upgrade, it is recommended to set use_boot_volume_key_as_default to true. Alternatively set it to false if you don't mind infrastructure being recreated. (#721) (3cb1b37)

v4.1.0

4.1.0 (2024-07-30)

Features

• Support added to create or restore VSI volumes to existing storage snapshots. The following new input variables have been added for this feature:
  - snapshot_consistency_group_id
  - boot_volume_snapshot_id
  - block_storage_volumes.snapshot_id (new property in existing map)
  - manage_reserved_ips (use to assign same reserved VSI instance IP address if recreating)
  - use_static_boot_volume_name (use to keep boot volume names tied to VSI hostnames, instead of random generated name) (#685) (666f518)

v4.0.1

4.0.1 (2024-06-11)

Bug Fixes

• remove upper limit for required terraform version (#684) (7821a8f)

v4.0.0

4.0.0 (2024-05-13)

Features

• In previous versions, it was found that adding or removing VSIs after they have been initially created by this module can cause VSIs to be destroyed and recreated due to the naming convention and logic being used. In order to fix this, the naming convention has changed in v4 of the module to be prefix- + the last 4 digits of the subnet ID + a sequential number for each subnet. For example, prefix-3ad7-001. (#610) (3790100)

BREAKING CHANGES

• Due to the refactoring work, if you are upgrading from an older version of this module to v4, you will see terraform wanting to destroy and recreate VSIs (and associated resources). To prevent this, please follow the upgrade steps in Updating from v3 to v4

v3.3.0

3.3.0 (2024-04-19)

Features

• functionality added to create Network Load Balancer(NLB). When the profile value in the load_balancers input is set as network-fixed, it signifies to setup an NLB. An existing subnet can be provided to provision NLB otherwise NLB uses the first subnet from the subnets list. Subsequently, a listener, a pool, and pool members are connected to the NLB. (#654) (0460e99)

v3.2.4

3.2.4 (2024-03-18)

Bug Fixes

• increase timeout for load balancer deployment (#636)
  Deployment timeout for load balancer set to 45 minutes (446f4ed)

v3.2.3

3.2.3 (2024-02-28)

Bug Fixes

• extend the required terraform version to < 1.7 (#627) (59f3b55)