alias_ip_range in google_compute_instance not maintaining IPs in proper order as of 5.41

[mj790]

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 me too comments, 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.
• If an issue is assigned to a user, that user is claiming responsibility for the issue.
• Customers working with a Google Technical Account Manager or Customer Engineer can ask them to reach out internally to expedite investigation and resolution of this issue.

Terraform Version & Provider Version(s)

Terraform v1.9.7 on windows_amd64

• provider registry.terraform.io/hashicorp/google v6.4.0

Affected Resource(s)

google_compute_instance

Terraform Configuration

resource "google_compute_instance" "vm" {

  name        = "testvm"
  hostname    = "testvm"
  machine_type = "n1-standard-1"
  zone                = "us-central1-a"
  project             = "testproject"

  boot_disk {
    initialize_params {
       image = "debian-cloud/debian-11"
    }
  }

  network_interface {
    subnetwork         = "mysubnet" #10.10.10.0/24
    subnetwork_project = "mysubnet-project"
    alias_ip_range {
        ip_cidr_range = "/32"
    }
     alias_ip_range {
        ip_cidr_range = "10.10.10.2/32"
    }
  }

}

Debug Output

No response

Expected Behavior

terraform plan right after the apply does not show any changes

Actual Behavior

terraform plan wants to modify one of the IPs and makes things worse by deleting/mixing up IPs if allowed to proceed

Steps to reproduce

1. terraform apply
2. terraform plan

Important Factoids

Previous to v5.41 everything was fine. Starting in v5.41 this issue occurs and seems related to the fix for alias_ip_range in 19015. Seems it might be the call to tpgresource.SortMapsByConfigOrder in compute_instance_helpers.go that is causing the issue because it's changing the order of the IPs?

I depend on the order of the IPs in state matching the order of the code shows (given there is no unique key to access them) and them being flipped is an issue (and it's even an issue for terraform given it can't create the vm without wanting to change it immediately after)

References

No response

b/372243345

[karolgorc]

Yes this is because of tpgresource.SortMapsByConfigOrder and the fact that if /32 is provided it creates a random address and can't really sort it on the first apply. This is used to normalize the table of the IP ranges to what's returned from the API. Without it it creates another permadiff because the ip_ranges won't be sorted properly

A quick workaround is to shift the order of alias_ip_range blocks in your terraform. In this example put the /32 under "10.10.10.2/32". This will get rid of the plan diff

Will look into handling this

Here is this exact case after some log.Prints API data [map[ip_cidr_range:10.10.10.6/32 subnetwork_range_name:] map[ip_cidr_range:10.10.10.5/32 subnetwork_range_name:]]

Config data [map[ip_cidr_range:/32 subnetwork_range_name:] map[ip_cidr_range:10.10.10.5/32 subnetwork_range_name:]]

[karolgorc]

After some testing i think that this field's logic should change entirely. Sorting this isn't really a viable solution contrary to what the magic-modules documentation says.

First of all this from line 2038 in resource_compute_instance.go shouldn't really be a thing in the API but it is

// Alias IP ranges cannot be updated; they must be removed and then added
// unless you are changing subnetwork/network

I will test if instances.Update has the same behavior as instances.UpdateNetworkInterface. And if it does i think there should be a solution here that doesn't rely on sorting and a diff check that completely ignores the order of these elements.

Another way to go is to rollback the changes made in 19015 and just accept the fact that we will clear this table when changing something as an API limitation. This seems like a better solution because making an entire new logic could potentially cause more edge-cases and overhead