Provider version 1.21.0 - Undefined attributes being updated

[zippanto]

Hi,

With the new provider version 1.21.0 we are seeing the following behaviour. Presumably this is caused by the fix for #332 / Fix variables could not been removed/reset issue.

When applying the plan resources that have certain attributes undefined are being updated to null value. Some of these will cause an error - for example fortios_system_global > gui_device_lattitude - some others will not cause an error, but will be updated on every subsequent apply - for example fortios_router_ospf > summary_address > id. I don't think this behaviour is intended. Please see below for a few examples where this issue is apparent:

  # fortios_system_global.global will be updated in-place
  ~ resource "fortios_system_global" "global" {
      - alias                                    = "FWF61EXX11111111" -> null
      - gui_device_latitude                      = "12.345678" -> null
      - gui_device_longitude                     = "-1.234567" -> null
        id                                       = "SystemGlobal"
        # (297 unchanged attributes hidden)
    }

  # fortios_router_ospf.ospf will be updated in-place
  ~ resource "fortios_router_ospf" "ospf" {
        id                                = "RouterOspf"
        # (28 unchanged attributes hidden)

      ~ summary_address {
          - id        = 1 -> null
            # (3 unchanged attributes hidden)
        }

        # (6 unchanged blocks hidden)
    }

  # fortios_systemsnmp_community.snmp_community will be updated in-place
  ~ resource "fortios_systemsnmp_community" "snmp_community" {
        id                    = "1"
        name                  = "community_string"
        # (16 unchanged attributes hidden)

      ~ hosts {
          - id                      = 1 -> null
            # (6 unchanged attributes hidden)
        }
    }

  # fortios_user_group.firewall_admins will be updated in-place
  ~ resource "fortios_user_group" "firewall_admins" {
        id                       = "Admins"
        name                     = "Admins"
        # (22 unchanged attributes hidden)

      ~ match {
          - id          = 1 -> null
            # (2 unchanged attributes hidden)
        }

        # (1 unchanged block hidden)
    }

Please advise.

Thanks.

[MaxxLiu22]

Hi @zippanto ,

Thank you for bringing this issue to our attention. You are correct; our provider has recently begun comparing all arguments to support the unset feature, which may have caused this problem. As a temporary solution, you may consider downgrading Terraform FOS to the previous version or ignoring these arguments in the lifecycle configuration. We are actively working on a patch to address this issue and expect to release it soon. We sincerely apologize for any inconvenience this may have caused, and we greatly appreciate your continued support of our product. Let me know if you still have other questions.

resource "fortios_system_global" "trname" {
  admin_sport = 443
  lifecycle {
    ignore_changes = [
      gui_device_latitude
    ]
  }
}

resource "fortios_systemsnmp_community" "trname" {
  events = "cpu-high mem-low log-full intf-ip vpn-tun-up vpn-tun-down ha-switch ha-hb-failure ips-signature ips-anomaly av-virus av-oversize av-pattern av-fragmented fm-if-change bgp-established bgp-backward-transition ha-member-up ha-member-down ent-conf-change av-conserve av-bypass av-oversize-passed av-oversize-blocked ips-pkg-update ips-fail-open faz-disconnect wc-ap-up wc-ap-down fswctl-session-up fswctl-session-down load-balance-real-server-down per-cpu-high"
  fosid  = 1
  name   = "fdsie"
  hosts {
    source_ip = "10.160.88.187"
    ip        = "1.2.3.4/32"
    ha_direct = "enable"
  }
  lifecycle {
    ignore_changes = [
      hosts[0].id
    ]
  }
}

Thanks,
Maxx

[zippanto]

Hi @MaxxLiu22,

Thanks for the swift response. No problem at all we were only testing the new provider version in the lab so there was no inconvenience.

Thanks.

[zippanto]

Hi @MaxxLiu22,

We are testing the new version 1.21.1. Unfortunately it seems some things are still not working as expected.

One issue that was not apparent to us and so we didn't highlight it in the original report is that there seems to be a change in behaviour when setting an attribute to null on a resource. Previously when the attribute was set to null it would mean the value of that attribute on the firewall would not be changed. In this version when the attribute is set to null it unsets the attribute. Could you please clarify what the intended behaviour is? Would that be the intended behaviour across all resources and attributes? It's important for us to understand as we have been relying on the previous behaviour. Please see below for an example:

  # fortios_routerbgp_neighbor.bgp_neighbor will be updated in-place
  ~ resource "fortios_routerbgp_neighbor" "bgp_neighbor" {
        id                                = "10.1.1.2"
      - local_as                          = 12345 -> null
        # (157 unchanged attributes hidden)
    }

An example where an id is trying to be set. As mentioned before this will update successfully, but the same change will be shown as an update on every subsequent apply.

  # fortios_router_bgp.bgp will be updated in-place
  ~ resource "fortios_router_bgp" "bgp" {
        id                                 = "RouterBgp"
        # (56 unchanged attributes hidden)

      ~ aggregate_address {
          - id           = 1 -> null
            # (3 unchanged attributes hidden)
        }

        # (7 unchanged blocks hidden)
    }

An example where attributes that are not defined on the resource are trying to be set null. As mentioned before this will error, because one of the attributes cannot be unset (vlanid in this example).

  # fortios_system_interface.interface will be updated in-place
  ~ resource "fortios_system_interface" "interface" {
      - alias                                      = "Example Alias" -> null
        id                                         = "internal1.1234"
        name                                       = "internal1.1234"
      - vlanid                                     = 1234 -> null
        # (221 unchanged attributes hidden)
    }

Please advise.

Thanks.

[zippanto]

A few more examples where an id is trying to be set:

  # fortios_systemdhcp_server.dhcp_server will be updated in-place
  ~ resource "fortios_systemdhcp_server" "dhcp_server" {
        id                           = "1"
        # (47 unchanged attributes hidden)

      ~ ip_range {
          - id         = 1 -> null
            # (5 unchanged attributes hidden)
        }

      ~ options {
          - id        = 1 -> null
            # (6 unchanged attributes hidden)
        }
    }

# fortios_system_sdwan.sdwan will be updated in-place
  ~ resource "fortios_system_sdwan" "sdwan" {
        id                       = "SystemSdwan"
        # (11 unchanged attributes hidden)

      ~ service {
          - id                       = 1 -> null
            name                     = "01-service"
            # (45 unchanged attributes hidden)

            # (4 unchanged blocks hidden)
        }
      ~ service {
          - id                       = 2 -> null
            name                     = "02-service"
            # (45 unchanged attributes hidden)

            # (22 unchanged blocks hidden)
        }

        # (7 unchanged blocks hidden)
    }

  # fortios_router_accesslist.accesslist will be updated in-place
  ~ resource "fortios_router_accesslist" "accesslist" {
        id                    = "acl"
        name                  = "acl"
        # (3 unchanged attributes hidden)

      ~ rule {
          - id          = 1 -> null
            # (5 unchanged attributes hidden)
        }
      ~ rule {
          - id          = 2 -> null
            # (5 unchanged attributes hidden)
        }
    }

Thanks.

[MaxxLiu22]

Hi @zippanto ,

"Apologies for any inconvenience. Starting from version 1.21.0, in Terraform for FortiOS, setting attributes to null is sending null through API, which is typically set them to 0 or empty (though some exceptions may require separate handling). This change stems from customer requests, such as setting allowaccess to empty or removing neighbor, as discussed in issue 326 and issue 332.

Our aim is to offer flexibility to unset any arguments where an empty value is meaningful. In cases where id is set to null (0), this is not meaningful, and FortiOS does not accept it even no error raised. We plan to improve this behavior on the Terraform side. However, local_as and alias can be set to empty and are accepted by FortiOS, so if you prefer not to modify this part, you may add them to your Terraform files. Setting vlanid to 0 is also not meaningful and is not accepted by FortiOS and raise an error. Although this argument is required when creating a VLAN interface via Terraform, I’ll discuss this with the development team. In the meantime, please ensure that it is set in your Terraform files to enable proper functionality."

Thanks,
Maxx