CiscoDevNet/terraform-provider-nxos

Provider produced inconsistent result after apply with nxos_spanning_tree_interface

aj-cruz opened this issue · 3 comments

Terraform Version

Terraform v1.2.9
on linux_amd64
+ provider registry.terraform.io/netascode/nxos v0.3.22

Affected Resource(s)

  • nxos_spanning_tree_interface

Terraform Configuration Files

resource "nxos_spanning_tree_interface" "STP_Ports" {
  depends_on = [
    nxos_physical_interface.Trunks,
    nxos_physical_interface.Access,
    nxos_rest.Port_Channel_Trunk_Interfaces,
    nxos_rest.Port_Channel_Access_Interfaces
  ]

  for_each = {
    for int in concat(
      local.trunk_ports,
      local.access_ports,
      local.po_trunk_interfaces,
      local.po_access_interfaces,
      local.shared_trunk_ports,
    local.shared_access_ports) : contains(keys(int), "int") ? "${int.dev_name}/${int.int}" : "${int.dev_name}/${int.po_id}" => int
  }

  device       = each.value.dev_name
  interface_id = contains(keys(each.value), "int") ? each.value.int : "po${each.value.po_id}"
  mode         = each.value.stp_port_type
  ctrl         = "unspecified"
}

Debug Output

Panic Output

Expected Behavior

Resource created.

Actual Behavior

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to nxos_spanning_tree_interface.STP_Ports["Prod-ACCESS-2/eth1/1"], provider "provider[\"registry.terraform.io/netascode/nxos\"]" produced an unexpected new value: .ctrl: was cty.StringVal("unspecified"), but
│ now cty.StringVal("").
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform apply

Important Factoids

Here's what the apply says is being created for that resource instance:

  # nxos_spanning_tree_interface.STP_Ports["Prod-ACCESS-2/eth1/1"] will be created
  + resource "nxos_spanning_tree_interface" "STP_Ports" {
      + admin_state  = "enabled"
      + bpdu_filter  = "default"
      + bpdu_guard   = "default"
      + cost         = 0
      + ctrl         = "unspecified"
      + device       = "Prod-ACCESS-2"
      + guard        = "default"
      + id           = (known after apply)
      + interface_id = "eth1/1"
      + link_type    = "auto"
      + mode         = "network"
      + priority     = 128
    }

References

To be honest, I am not sure if the ctrl attribute is of any use at all. Changing it to whatever value does not change the CLI configuration. Can you try setting it to bpdu-guard (or bpdu-filter) and see if it works. Those values are at least retained. I might remove the attribute in the next release if there is no use for it.

I'll give it a try when I get a moment. Yeah I see that attribute in the DME but I couldn't figure out the purpose of it. I have noticed in other resources though that from time to time it might change on a given resource based on configs from other resources causing the 1st resource to always think it needs to be updated. I have a few cases of that happening so I've just ignored ctrl in those cases to get around it.

ctrl attribute has been removed in v0.4.0.