Issue when removing/replacing a Routing policy from a Routing Zone

[coterv]

Environment

• Terraform v1.6.2
• Provider: v0.39.0
• Apstra: v4.2.0

Brief description

When you attempt to remove / replace a route policy from a routing zone that was initially created with that routing policy, no changes are produced.

This issue may be related to that reported in https://github.com/Juniper/terraform-provider-apstra/issues/420.

Logs

• STEP 1: Create RZ "rz_test" initially with RP Result: OK

resource "apstra_datacenter_routing_zone" "prueba" {
  blueprint_id = local.blueprint_ids["B_TB"]
  name         = "rz_test"
  vlan_id      = "17"
  vni          = "6666"
  routing_policy_id = try(apstra_datacenter_routing_policy.routing_policies["B_TB.rp_test"].id, null)
}

Terraform change:

# module.blueprints.apstra_datacenter_routing_zone.prueba will be created
  + resource "apstra_datacenter_routing_zone" "prueba" {
      + blueprint_id             = "189f19a6-43bb-49f8-beb5-76aae447013b"
      + had_prior_vlan_id_config = (known after apply)
      + had_prior_vni_config     = (known after apply)
      + id                       = (known after apply)
      + name                     = "rz_test"
      + routing_policy_id        = "4YjWG18wiSWFUn82VgQ"
      + vlan_id                  = 17
      + vni                      = 6666
    }

terraform.tfstate:

"attributes": {
      "blueprint_id": "189f19a6-43bb-49f8-beb5-76aae447013b",
      "dhcp_servers": null,
      "had_prior_vlan_id_config": true,
      "had_prior_vni_config": true,
      "id": "j8679TCYjZVULrT-g1c",
      "name": "rz_test",
      "routing_policy_id": "4YjWG18wiSWFUn82VgQ",
      "vlan_id": 17,
      "vni": 6666
},

• STEP 2: Remove the RP from RZ "rz_test" Result: No changes, but an Apstra commit is executed

resource "apstra_datacenter_routing_zone" "prueba" {
  blueprint_id = local.blueprint_ids["B_TB"]
  name         = "rz_test"
  vlan_id      = "17"
  vni          = "6666"
  # routing_policy_id = try(apstra_datacenter_routing_policy.routing_policies["B_TB.rp_test"].id, null)
}
}

Terraform change:

 # module.blueprints.apstra_blueprint_deployment.deploy["B_TB"] will be created
  + resource "apstra_blueprint_deployment" "deploy" {
      + blueprint_id            = "189f19a6-43bb-49f8-beb5-76aae447013b"
      + comment                 = "[$USER] Deployment by Terraform {{.TerraformVersion}}, Apstra provider {{.ProviderVersion}}."
      + has_uncommitted_changes = (known after apply)
      + revision_active         = (known after apply)
      + revision_staged         = (known after apply)
    }

terraform.tfstate:

 "attributes": {
            "blueprint_id": "189f19a6-43bb-49f8-beb5-76aae447013b",
            "dhcp_servers": null,
            "had_prior_vlan_id_config": true,
            "had_prior_vni_config": true,
            "id": "j8679TCYjZVULrT-g1c",
            "name": "rz_test",
            "routing_policy_id": "4YjWG18wiSWFUn82VgQ",
            "vlan_id": 17,
            "vni": 6666
          },

• STEP 3: Apply a non-existing RP "dummy" to RZ "rz_test" Result: No changes

resource "apstra_datacenter_routing_zone" "prueba" {
  blueprint_id      = local.blueprint_ids["B_TB"]
  name              = "rz_test"
  vlan_id           = "17"
  vni               = "6666"
  routing_policy_id = try(apstra_datacenter_routing_policy.routing_policies["dummy"].id, null)
}

Terraform change:

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

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

terraform.tfstate:

"attributes": {
            "blueprint_id": "189f19a6-43bb-49f8-beb5-76aae447013b",
            "dhcp_servers": null,
            "had_prior_vlan_id_config": true,
            "had_prior_vni_config": true,
            "id": "j8679TCYjZVULrT-g1c",
            "name": "rz_test",
            "routing_policy_id": "4YjWG18wiSWFUn82VgQ",
            "vlan_id": 17,
            "vni": 6666
          },

[chrismarget-j]

If I understand correctly, I think we're seeing expected terraform behavior here.

In step 2, omitting the routing_policy_id optional attribute is the same thing as supplying routing_policy_id = null

In step 3, the try() function winds up supplying the same value: routing_policy_id = null

Essentially, in both cases, we've opted out of supplying a value for an optional attribute. Terraform thinks we don't care about the value.

Terraform has no concept of a default routing policy - that choice is made (during initial RZ creation) by the Apstra API.

Changing the policy ID to a different value (whether it's the default policy ID or some user-created policy) should have the expected effect ... and we're still looking into #420.

[coterv]

Hi Chris, I apologize for the confusion earlier. For some reason I had misunderstood that omitting the routing_policy_id is not equivalent to asking for its removal, but rather to simply not providing this optional variable.

I have attempted to replace the initially assigned RP with another existing RP and the error outlined in https://github.com/Juniper/terraform-provider-apstra/issues/420 occurred as expected.

Therefore, I think we can close this issue and direct the focus to the issue at https://github.com/Juniper/terraform-provider-apstra/issues/420.

[chrismarget-j]

You're not the first to have been surprised by no "revert to default" behavior under these circumstances. I've seen it come up the Hashicorp Discuss server a few times.

From the provider standpoint, we don't even learn that you've eliminated the attribute because terraform concludes there's no work to do without ever invoking our Update() method, so there's not much to do about it.

There's a huge asymmetry between "get the default policy by doing nothing" (on initial apply) and "get the default policy by jumping through hoops to learn it and then specifying it as an optional attribute" (on subsequent apply), and I can understand that it would be surprising/frustrating to bump into.