Use of many ip_prefixes in an ns1_record results in broken change detection

[davidkemper]

Using many ip_prefixes is not idempotent. Every plan/apply shows changes even when the terraform is unchanged.

I believe this is because on the server side NS1 re-orders the ip prefix list, which you can see happen on their console. Note that you may need more than a couple ip prefixes to exhibit this behavior.

If NS1 will not guarantee consistent round-tripping on their api, then the terraform provider itself should compare the plan and actual lists using by breaking apart the attribute string and comparing the two sets of ip prefixes more directly.

Terraform Version

Terraform v0.12.9

Affected Resource(s)

• ns1-record

Terraform Configuration Files

resource "ns1_record" "alias" {
  zone   = var.zone
  domain = var.domain
  type   = "ALIAS"
  ttl    = var.ttl

  answers {
    answer = "..."
    meta = {
      ...
      ip_prefixes = "join(",", [
        "3.248.0.0/13",
        "13.248.96.0/24",
        "13.248.113.0/24",
        "13.248.118.0/24",
        "13.248.119.0/24",
        "13.248.121.0/24",
        ...
      ])
    }
  }
  ...
}

Note that I'm only using join so that I can put each ip block on its own line; this makes it easy to detect when there are changes using the normal source control commands.

Expected Behavior

The expected behavior is that applying unchanged terraform (i.e., the list of ip_prefixes does not change) should be idempotent.

I should be able to deploy the terraform, and the next plan should show no changes.

Actual Behavior

Every plan / apply shows changes in the list of IP ranges.

The code that I wrote to generate this terraform is careful to sort the ip prefix list into a stable order (done by octet). I note that after I terraform apply and view the actual record in the NS1 console, the ip prefixes have been shuffled into a different order.

(My guess is that on the NS1 server side it passes through some kind of hash set, and gets re-ordered by their hashing function; again, this is a guess.)

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. Create a record with a number of ip prefixes; there needs to be enough to be subject to reordering.
2. terraform apply
3. Note in the console that the order has changed.
4. terraform apply
5. Verify that every apply shows a change in the ip prefixes, even though the terraform source has not changed.

[rupa]

hi, thanks for reporting this. I can reproduce and confirm this is not intended behavior. we'll get a fix for this going ASAP

[davidkemper]

Fantastic! Thanks for the quick attention.

[davidkemper]

Final comment from me... this was released the other day, and it indeed fixes the issue for me.