Provider v0.84.0: Binding vlans to switch_ids(without binding constructor) produces inconsistent result after apply and errors out. Apstra 5.1

[skameswa]

Here is the TF code for adding vlan and its binding:

/*
data "apstra_datacenter_systems" "vn_10002_leaf_ah1-dc-b6-sw-1" {
blueprint_id = apstra_datacenter_blueprint.instantiation.id
filters = [
{
role = "leaf"
hostname = "ah1-dc-b6-sw-1"
system_type = "switch"
}
]
}

data "apstra_datacenter_systems" "vn_10002_leaf_ah1-dc-b6-sw-2" {
blueprint_id = apstra_datacenter_blueprint.instantiation.id
filters = [
{
role = "leaf"
hostname = "ah1-dc-b6-sw-2"
system_type = "switch"
}
]
}

resource "apstra_datacenter_virtual_network" "vn_10002" {
name = "vl2"
description = "AH-unix"
blueprint_id = apstra_datacenter_blueprint.instantiation.id
type = "vxlan"
routing_zone_id = data.apstra_datacenter_routing_zone.SSG.id
ipv4_connectivity_enabled = "false"
ipv4_virtual_gateway_enabled = "false"
vni = "10002"
reserve_vlan = "false"

export_route_targets = ["65310:10002", "65310:268445458"]
import_route_targets = ["65310:10002", "65310:268445458"]

bindings = {

            one(data.apstra_datacenter_systems.vn_10002_leaf_ah1-dc-b6-sw-1.ids) = {
                "vlan_id" = "2"
            },

            one(data.apstra_datacenter_systems.vn_10002_leaf_ah1-dc-b6-sw-2.ids) = {
                "vlan_id" = "2"
            },

        }

}
*/

Here is the error message:

╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to apstra_datacenter_virtual_network.vn_10011, provider "provider["registry.terraform.io/juniper/apstra"]" produced an unexpected new value: .bindings: element "3cSGPFxXVKWLvhfGTA"
│ has vanished.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to apstra_datacenter_virtual_network.vn_10011, provider "provider["registry.terraform.io/juniper/apstra"]" produced an unexpected new value: .bindings: element "rsNRTTbpZSwD-IR8Tw"
│ has vanished.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to apstra_datacenter_virtual_network.vn_10011, provider "provider["registry.terraform.io/juniper/apstra"]" produced an unexpected new value: .bindings: new element
│ "TBUP7wTacS5vbuIPuA" has appeared.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

[chrismarget-j]

Hello @skameswa, thank you for opening this issue.

Are the switches in question are members of an MLAG or ESI-LAG pair?

For individual switches, you can use their IDs directly when creating bindings.

For switches which are members of a redundancy group, the API accepts either of these two:

• Both switch IDs together in one call
• The ID of the redundancy group

If you send both switch IDs, the API accepts them but then swaps in the redundancy group ID. There’s not much we can do about that behavior from the terraform side. Heck, we can’t even tell which ID (individual or group) has been passed in. Resolving this complexity is the main reason the binding constructor data source exists. The example in the documentation tries to spell that out, but there’s probably room for further clarification.

Please consider this configuration?

data "apstra_datacenter_systems" "vn_10002_leaf_ah1-dc-b6-sw-1-2" {
  blueprint_id = apstra_datacenter_blueprint.instantiation.id
  filters = [
    {
      role        = "leaf"
      hostname    = "ah1-dc-b6-sw-1"
      system_type = "switch"
    },
    {
      role        = "leaf"
      hostname    = "ah1-dc-b6-sw-2"
      system_type = "switch"
    },
  ]
}

data "apstra_datacenter_virtual_network_binding_constructor" "vn_10002_leaf_ah1-dc-b6-sw-1-2_vn_10002" {
  blueprint_id = apstra_datacenter_blueprint.instantiation.id
  vlan_id      = 2
  switch_ids   = [data.apstra_datacenter_systems.vn_10002_leaf_ah1-dc-b6-sw-1-2.ids]
}

resource "apstra_datacenter_virtual_network" "vn_10002" {
  name                         = "vl2"
  description                  = "AH-unix"
  blueprint_id                 = apstra_datacenter_blueprint.instantiation.id
  type                         = "vxlan"
  routing_zone_id              = data.apstra_datacenter_routing_zone.SSG.id
  ipv4_connectivity_enabled    = "false"
  ipv4_virtual_gateway_enabled = "false"
  vni                          = "10002"
  reserve_vlan                 = "false"

  export_route_targets = ["65310:10002", "65310:268445458"]
  import_route_targets = ["65310:10002", "65310:268445458"]

  bindings = data.apstra_datacenter_virtual_network_binding_constructor.vn_10002_leaf_ah1-dc-b6-sw-1-2_vn_10002.bindings
}

Additionally, if you inspect the output of the data sources, I expect you’ll find that this one:

terraform state show apstra_datacenter_systems.vn_10002_leaf_ah1-dc-b6-sw-1-2

Returns the two IDs which have “vanished” according to the error (the individual switch IDs).

While this one:

terraform state show data.apstra_datacenter_virtual_network_binding_constructor.vn_10002_leaf_ah1-dc-b6-sw-1-2_vn_10002

Returns the ID which has “appeared” according to the error (the redundancy group ID).

/chris