Terraform plan identifies non-existent changes in address groups / service object groups.

[andyburridge]

Hi,

I'm using the following 2 resources:

fortios_firewall_addrgrp
fortios_firewallservice_group

In combination with a for_each loop in the resource allocation similar to the following :

resource "fortios_firewall_addrgrp" "addrgrp" {
  for_each = var.address_groups

    allow_routing = "disable"
    color         = 3
    exclude       = "disable"
    name          = each.key

    dynamic "member" {
      for_each = toset(each.value)
        content {
          name = member.value
        }
    }
}

......

resource "fortios_firewallservice_group" "custom-service-object-groups" {
  for_each = var.custom_service_object_groups

    color = 0
    name  = each.key
    proxy = "disable"

    dynamic "member" {
      for_each = toset(var.custom_service_object_groups[each.key]["services"])
      content {
        name = member.value
      }
    }
}

And variables defined as follows:

address_groups = {
    "srv-pim-ssh-links-nhbr" = [
      "srv-nhbr-test-pipe-1",
      "h_10.160.32.77-chelford"
    ]
}

.....

custom_service_object_groups = {
  "ORACLE-HVR-SERVICES" = {
    "services" = ["ORACLE-DB-ALT-1522", "ORACLE-HVR-ALT-5343","ORACLE-DB"]
  }
}

Every time the Terraform plan runs, it proposes to make a change to the object groups in the form of replacing the order of the members in the group. Once we apply the plan changes with Terraform apply, it actually completes fine and makes no change to the running code on the firewall, but false alterations showing as ready to be actioned changes in the plan complicates the CICD process.

 # fortios_firewall_addrgrp.addrgrp["srv-pim-ssh-links-nhbr"] will be updated in-place
  ~ resource "fortios_firewall_addrgrp" "addrgrp" {
        id                    = "srv-pim-ssh-links-nhbr"
        name                  = "srv-pim-ssh-links-nhbr"
        # (10 unchanged attributes hidden)

      ~ member {
          ~ name = "srv-nhbr-test-pipe-1" -> "h_10.160.32.77-chelford"
        }
      ~ member {
          ~ name = "h_10.160.32.77-chelford" -> "srv-nhbr-test-pipe-1"
        }
    }

.......

# fortios_firewallservice_group.custom-service-object-groups["ORACLE-HVR-SERVICES"] will be updated in-place
  ~ resource "fortios_firewallservice_group" "custom-service-object-groups" {
        id                    = "ORACLE-HVR-SERVICES"
        name                  = "ORACLE-HVR-SERVICES"
        # (5 unchanged attributes hidden)

      ~ member {
          ~ name = "ORACLE-DB-ALT-1522" -> "ORACLE-DB"
        }
      ~ member {
          ~ name = "ORACLE-HVR-ALT-5343" -> "ORACLE-DB-ALT-1522"
        }
      ~ member {
          ~ name = "ORACLE-DB" -> "ORACLE-HVR-ALT-5343"
        }
    }

Is this an issue, or is there something functionally incorrect with the way I'm using the resources?

[MaxxLiu22]

Hi @andyburridge ,

Thank you for bringing this issue to our attention. It seems that the order of creation might have changed after Terraform deployed the configuration to the FGT. Could you kindly add dynamic_sort_subtable = true to your resources and recreate the objects? This should help organize your blocks before sending the configuration to the FGT. If the issue continues, would you mind sharing your Terraform FOS version and FGT version? The issue may be related to a version difference.

Thanks,
Maxx

[andyburridge]

Thanks @MaxxLiu22, appreciate the quick response and I'll try this soon.

Would I need to delete the resources and then recreate them for this to take effect or can I simply add this parameter into the existing resource? Or will adding the parameter actually force recreation?

The reason I ask is that these resources are already in use in policies on a production device.

If I need to delete and recreate all of these resources then this will take longer to test.

[MaxxLiu22]

Hi @andyburridge ,

Ideally, you could delete the resource and recreate it, as the element order should be fixed on FGT once you first apply your configuration. However, you might also want to try adding dynamic_sort_subtable = true and then applying it. This typically shouldn't force a recreation, but you can double-check during the plan stage, as it will notify you if recreation is required. May I ask which versions of FOS and the Terraform FOS provider you're using? I wasn't able to reproduce the issue on my side, even without setting dynamic_sort_subtable, using Terraform FOS 1.21.0 and FOS 7.4.5.

Thanks,
Maxx

[andyburridge]

Hi @MaxxLiu22

Adding dynamic_sort_subtable = true to my existing resources fixed the issue on ~60 resources, but bizarrely not 3 which still exhibit the same behaviour.

I've checked and I'm using FOS 7.2.7 and Provider 1.16.0, so a pretty old version of the provider.

I will try upgrading my provider to the latest version, and if I still have the issue following this then it is not too much of a hardship to delete and recreate the remaining 3 troublesome resources.

Thanks for your assistance.