new distributed firewall rule with above_rule_id gets the id of the first already existing firewall rule

[ghost]

Hello,

Description

When using resource.vcd_nsxt_distributed_firewall_rule to insert a rule in the distributed firewall rules list, with the above_rule_id argument set to the ID of the last existing rule in the list (default drop rule), it results in terraform creating the rule as required however in the state a wrong rule is saved.

When creating a new rule with above_rule_id set to the ID of the first existing rule, then it works OK.

Terraform Version

Terraform v1.7.1
on linux_amd64

• provider registry.terraform.io/vmware/vcd v3.11.0

Also with Terraform 1.5.5 and vcd 3.10.0

Affected Resource(s)

Please list the resources as a list, for example:

• vcd_nsxt_distributed_firewall_rule

Terraform Configuration Files

data "vcd_vdc_group" "dcg" {
  name = var.default_dcg_name
}

data "vcd_nsxt_edgegateway" "edgegw" {
  org      = var.vcd_org
  name     = var.default_edge_gw
  owner_id = data.vcd_vdc_group.dcg.id
}

resource "vcd_nsxt_ip_set" "ipset1" {
  org             = var.vcd_org
  edge_gateway_id = data.vcd_nsxt_edgegateway.edgegw.id

  name = "ipset1"

  ip_addresses = ["10.0.40.2"
  ]
}

data "vcd_nsxt_distributed_firewall" "dfw" {
  org          = var.vcd_org
  vdc_group_id = data.vcd_vdc_group.dcg.id
}

data "vcd_nsxt_distributed_firewall_rule" "defaultdroprule" {
  org          = var.vcd_org
  vdc_group_id = data.vcd_vdc_group.dcg.id

  name = var.default_dfw_drop_rule
}

resource "vcd_nsxt_distributed_firewall_rule" "rule1" {
  action = "ALLOW"
  #above_rule_id = "811e85af-e938-495f-bd0f-2a41cd00e254"
  above_rule_id = data.vcd_nsxt_distributed_firewall_rule.defaultdroprule.id
  direction     = "IN_OUT"
  enabled       = true
  ip_protocol   = "IPV4_IPV6"
  name          = "rule1_allow"
  org           = var.vcd_org
  source_ids    = [resource.vcd_nsxt_ip_set.ipset1.id]
  vdc_group_id  = data.vcd_vdc_group.dcg.id
}

Actual Behavior

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # vcd_nsxt_distributed_firewall_rule.rule1 will be created
  + resource "vcd_nsxt_distributed_firewall_rule" "rule1" {
      + above_rule_id               = "811e85af-e938-495f-bd0f-2a41cd00e254"
      + action                      = "ALLOW"
      + destination_groups_excluded = false
      + direction                   = "IN_OUT"
      + enabled                     = true
      + id                          = (known after apply)
      + ip_protocol                 = "IPV4_IPV6"
      + logging                     = false
      + name                        = "rule1_allow"
      + org                         = "xxx-xxx"
      + source_groups_excluded      = false
      + source_ids                  = [
          + "urn:vcloud:firewallGroup:x-x-x-x-x",
        ]
      + vdc_group_id                = "urn:vcloud:vdcGroup:x-x-x-x-x"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

vcd_nsxt_distributed_firewall_rule.rule1: Creating...
vcd_nsxt_distributed_firewall_rule.rule1: Creation complete after 4s [id=5259729e-2509-4e10-85c2-d8c21b799980]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

From above, 5259729e is the ID of the first rule that already existed in the rules list. Checking state with:

terraform state show vcd_nsxt_distributed_firewall_rule.rule1

# vcd_nsxt_distributed_firewall_rule.rule1:
resource "vcd_nsxt_distributed_firewall_rule" "rule1" {
    above_rule_id               = "811e85af-e938-495f-bd0f-2a41cd00e254"
    action                      = "ALLOW"
    destination_groups_excluded = false
    direction                   = "IN_OUT"
    enabled                     = true
    id                          = "5259729e-2509-4e10-85c2-d8c21b799980"
    ip_protocol                 = "IPV4"
    logging                     = false
    name                        = "eng_mgmt_allow"
    org                         = "xxxx-xxxxx-xxxx"
    source_groups_excluded      = false
    source_ids                  = [
        "urn:vcloud:firewallGroup:x-x-x-x-x",
    ]
    vdc_group_id                = "urn:vcloud:vdcGroup:x-x-x-x-x"
}

state contains the first rule that already existed in the list, instead of the actually created rule.

This then results in terraform trying to update the wrong rule in the firewall on next apply, to replace it's name, source_ids etc.

Expected Behavior

The vcd_nsxt_distributed_firewall_rule should have a new ID and is correctly saved in the state file and next terraform apply operation should have no other changes/updates.

Steps to Reproduce

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

1. terraform apply

Not using above_rule_id for the new rule results in the expected behavior, the new rule has a different new ID and is correctly saved in state and terraform apply has no other changes further.

[ghost]

@Didainius any possible update here?

[Didainius]

I am not yet 100% confident I can squeeze it in for this release, but I will try to.

[tyriis]

@Didainius thank you for your work, is there any known workaround? this is currently a blocker for us ;(

[Didainius]

@at-afa , @tyriis ,
I think I have found the bug and have a branch with possible fix. #1268 (my tests are passing)
Would you be able to validate?

[ghost]

Hi Didainius,

Thanks! I have compiled the bug-1202 branch (with go 1.22.3) and installed the 3.13.0 version of vcd provider. From the various tests done the bug seems resolved. The order of the rules is correct now. After applying the terraform config that creates the new rule, the second terraform plan shows no changes.

I have tested:

• create a new rule above default drop rule using above_rule_id
• destroy the above
• create a new rule above a new rule that is created with above_rule_id set to default drop rule id
• destroy one rule only then destroy all from above

Thanks again! +1

[Didainius]

The fix is now in main branch and will be released with provider version 3.13.