Skip to content

Secondary pod ip ranges in SharedVPC do not conform to ordering in map #3018

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

Open
1 of 4 tasks
jacklever-hub24 opened this issue Apr 9, 2025 · 5 comments
Open
1 of 4 tasks

Comments

@jacklever-hub24
Copy link
Contributor

Affected components

  • Fabric modules
  • FAST
  • Blueprints
  • Other

The problem

When a map of secondary ip ranges is entered in the subnet module the list is ordered by alphabetical order rather than the order entered in the list in the tfvars. This means any addition with a lower letter ordering will break the secondary ip ranges already existing as it'll try to modify the existing entries to conform to alphabetical order and rename them or change the ip addresses i.e.

        secondary_ip_range = {
          b = "192.168.2.0/24",
          c = "192.168.3.0/24"
        }

when a = "192.168.1.0/24" is added, even if it's added to the end of the list, it'll attempt to rename the existing members like this

      ~ secondary_ip_range {
          ~ ip_cidr_range           = "192.168.2.0/24" -> "192.168.1.0/24"
          ~ range_name              = "b" -> "a"
            # (1 unchanged attribute hidden)
        }
      ~ secondary_ip_range {
          ~ ip_cidr_range           = "192.168.3.0/24" -> "192.168.2.0/24"
          ~ range_name              = "c" -> "b"
            # (1 unchanged attribute hidden)
        }
      + secondary_ip_range {
          + ip_cidr_range = "192.168.3.0/24"
          + range_name    = "c"
        }

Release version

v38.0.0

Terraform version

v1.10.5

Steps to reproduce

Create a subnet with the above secondary ip ranges using the above config and create it, then modify the map and you'll see the matching output.

Expected behavior

Items are mapped by their names somehow and stay in their correct ordering even after an entry is removed. Only the added or removed entries should be modified.

Actual behavior

All items get re-ordered depending on the alphabetical order.

Additional context

No response

@jacklever-hub24
Copy link
Contributor Author

Potentially related to this tf discussion question https://discuss.hashicorp.com/t/preserve-order-with-dynamic-block/50055

@wiktorn
Copy link
Collaborator

wiktorn commented Apr 9, 2025

Terraform maps are always sorted alphabetically:

$ terraform console
> { "b": 1 , "a": 2 }
{
  "a" = 2
  "b" = 1
}

There is no way we can preserve the order in which it was entered. The only way to achieve what you need here, is to refactor the variable into map of objects with subnet range name and range, and use the map keys for ordering.

@jacklever-hub24
Copy link
Contributor Author

Would you like me to refactor this into the subnet index list?

I am willing to do this work to fix the issue we have, however it may break existing implementations as it'd be converting from map(name => iprange) to either map(number => secondary_range_object) or list(secondary_range_object). I'd be feeding the index into the key attribute of the dynamic block foreach.

@ludoo
Copy link
Collaborator

ludoo commented Apr 10, 2025

Would you like me to refactor this into the subnet index list?

Yes that would be nice, provided the refactor really addresses the issue and does not introduce new ones :)

I am willing to do this work to fix the issue we have, however it may break existing implementations as it'd be converting from map(name => iprange) to either map(number => secondary_range_object) or list(secondary_range_object). I'd be feeding the index into the key attribute of the dynamic block foreach.

list() is definitely better than using an explicit index.

@ludoo
Copy link
Collaborator

ludoo commented Apr 10, 2025

PS - Since this will also affect FAST, the change should be against the fast-dev branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants