unnecessary changes in azuread_named_location ip_ranges

[IdahoVandal]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritise this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritise the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureAD Provider) Version

• Terraform v1.0.9
• azuread v2.15.0

Affected Resource(s)

• azuread_named_location

Terraform Configuration Files

resource "azuread_named_location" "Test-Workstations" {
    display_name = "Test Workstations"
    ip {
        ip_ranges = [
            "10.0.1.1/32",
            "10.0.1.2/32",
        ]
        trusted = true
    }
}

Debug Output

Debug Output

Expected Behavior

Compare ip_ranges array regardless of sort order. Don't attempt updates if the array values match.

Actual Behavior

A change is attempted on the resource even though the values match.

  # azuread_named_location.Test-Workstations will be updated in-place
  ~ resource "azuread_named_location" "Test-Workstations" {
        id           = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
        # (1 unchanged attribute hidden)

      ~ ip {
          ~ ip_ranges = [
              - "10.0.1.1/32",
                "10.0.1.2/32",
              + "10.0.1.1/32",
            ]
            # (1 unchanged attribute hidden)
        }

        # (1 unchanged block hidden)
    }

Steps to Reproduce

1. terraform apply

Important Factoids

Multiple ip_ranges changes cause a failure to update. It is possible to run terraform with -target to correct each resource individually. Once it has been applied the issue resolves itself until the next change to ip_ranges.

[manicminer]

Hi @IdahoVandal, thanks for reporting this flapping diff - this looks like a potential ordering issue, which we should be able to address but due to Terraform limitations such a fix would require a breaking change to the schema. Before proceeding with that, could you confirm the following as it will help us figure out how the ordering of this field is behaving in API responses.

1. Are you explicitly ordering the IP ranges in your configuration?
2. Do you find that you have to reorder them in your configuration to make this diff/error go away?
3. Does it happen on the first apply after a change to the resource and then subsequently not?
4. Does this always happen or does it happen some of the time?

Any additional info you can provide in respect of the above would be really helpful, thanks again!