vcd_nsxt_firewall inserted rule at the top results in loads of changes and new rule-ids in NSXT

[rvvliet78]

Hi,

When inserting a new rule to the vcd_nsxt_firewall resource (anywhere other then the last one) the result is less then ideal. In the example below I created a new rule at the top named: "inserted before rule 1 Internet Access" I'm noticing that instead of adding one new rule at the top, each rule is changed, and the previous last rule is now newly created as the new last rule.

So the result of adding a new rule at the top is actually changing all the rules and creating a new last rule. This might be cosmetic, however when looking at the rule ID's (/ rule numbers) in the NSX managed it actually creates all new rules in NSX. I haven't tested this but I can imagine that it also "screws" up the rule hitcount.

When mimicking this in the Cloud Director UI, only a new rule is added, and all the other ID's stay as is.

We are using the NSX rule ID/number to identify it in the logging, so this behaviour leads to issues when troubleshooting. Lets say I am filtering the logs for a specific NSX rule id/number, and add a rule via terraform to test it, I need to create a new filter because these numbers have changed.

I think it would be logical that if you insert a rule that all other rules stay the same in VCD and NSX.

`Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: ~ update in-place

Terraform will perform the following actions:

vcd_nsxt_firewall.firewall will be updated in-place

~ resource "vcd_nsxt_firewall" "firewall" { id = "urn:vcloud:gateway:e987c477-4fad-4beb-acb8-cfb885ee5b60" # (2 unchanged attributes hidden)

  ~ rule {
      ~ destination_ids      = [
          + "urn:vcloud:firewallGroup:42b3f185-baef-4033-b331-05484af8b103",
        ]
        id                   = "009804df-1713-4b13-a242-6cfb4f20d78f"
      ~ name                 = "rule 1 Internet Access" -> "inserted before rule 1 Internet Access"
        # (7 unchanged attributes hidden)
    }
  ~ rule {
      ~ destination_ids      = [
          - "urn:vcloud:firewallGroup:c3a01cb1-bc4a-490d-80a3-d0b23598aecb",
        ]
      ~ direction            = "IN_OUT" -> "OUT"
        id                   = "0ae14206-62bd-4bee-ad5b-6d0838c5fc13"
      ~ name                 = "rule 2 sen to home" -> "rule 1 Internet Access"
        # (6 unchanged attributes hidden)
    }
  ~ rule {
      ~ destination_ids      = [
          - "urn:vcloud:firewallGroup:42b3f185-baef-4033-b331-05484af8b103",
          + "urn:vcloud:firewallGroup:c3a01cb1-bc4a-490d-80a3-d0b23598aecb",
        ]
      ~ direction            = "IN" -> "IN_OUT"
        id                   = "2e960343-007b-4acd-a8e3-b99bee2cf016"
      ~ name                 = "rule 3 home Access" -> "rule 2 sen to home"
      ~ source_ids           = [
          - "urn:vcloud:firewallGroup:c3a01cb1-bc4a-490d-80a3-d0b23598aecb",
          + "urn:vcloud:firewallGroup:42b3f185-baef-4033-b331-05484af8b103",
        ]
        # (5 unchanged attributes hidden)
    }
  + rule {
      + action          = "ALLOW"
      + destination_ids = [
          + "urn:vcloud:firewallGroup:42b3f185-baef-4033-b331-05484af8b103",
        ]
      + direction       = "IN"
      + enabled         = true
      + ip_protocol     = "IPV4"
      + logging         = false
      + name            = "rule 3 home Access"
      + source_ids      = [
          + "urn:vcloud:firewallGroup:c3a01cb1-bc4a-490d-80a3-d0b23598aecb",
        ]
    }
}

`