Terraform - API returns data in a different order, so terraform sees a meaningless change?

user_2216184 0
Viewed 255

I am seeing terraform want to change resources for meaningless changes (often related to the ordering of list type things). For example below, This resource has not changed, just the ordering returned this particular run from the APIs.

Can I change anything to prevent these sort of meaningless changes from showing up in plans and applys? Application Gateway and it's many blocks are another example where I see this occurring.

# azurerm_web_application_firewall_policy.owasp_only will be updated in-place
  ~ resource "azurerm_web_application_firewall_policy" "owasp_only" {
        id                  = "/subscriptions/ReallingInterestingGUID/resourceGroups/rg-apim/providers/Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/ccr-owasp-only"
        name                = "ccr-owasp-only"
        tags                = {
            "created-by"      = bob.jones@jones.com
            "terraform-stack" = "api-gateway"
        }
        # (4 unchanged attributes hidden)

      ~ managed_rules {

          ~ managed_rule_set {
              ~ type    = "Microsoft_BotManagerRuleSet" -> "OWASP"
              ~ version = "0.1" -> "2.2.9"
            }
          ~ managed_rule_set {
              ~ type    = "OWASP" -> "Microsoft_BotManagerRuleSet"
              ~ version = "2.2.9" -> "0.1"
            }
       }

        # (1 unchanged block hidden)
    }
terraform-provider-azure terraform
1 Answers

In situations where a Terraform provider misunderstands API-based normalization as if it were drift, the general immediate answer is to change your configuration to match the normalized form that the remote system expects.

In your case, it seems like that would mean to swap the order of the two managed_rule_set blocks in your configuration, so that the ordering matches what the remote API considers to be the normalized representation.

Unfortunately these normalization rules are not universally well-documented in the remote system documentation, and so developers can miss them when implementing the Terraform provider integrations. The "real" answer to this would be to add the missing logic to the provider to allow it to recognize when two configurations are considered by the remote system to be equivalent, but of course that's not typically something you can do immediately and must instead wait for a new version of the provider which includes that additional logic. Making your configuration match what the remote system expects is therefore a more practical change you can make without changing your provider version.

user_2818480
Related