Resource "nxos_spanning_tree_interface" cannot be destroyed when calling 'terraform destroy'

[Rossnunez]

I'm able to run a snippet like this and create the setting for the spanning-tree in a specific mode for this port:

resource "nxos_spanning_tree_interface" "TEST_SPANTREE" {
  for_each     = toset([for leaf in local.leafs : leaf.name])
  device       = each.key

  interface_id = "eth1/1"
  mode         = "edge"
}

When I call terraform destroy, on the terraform side, the object shows that it has been destroyed:

However, when I do a quality check on the interface, by running this command on the cisco switch: show running-config interface eth1/1

I get this output:

This is the problem. The setting was never cleared/destroyed.

I can use the resource nxos_physical_interface to enable a phy interface and then call the terraform destroy command to undo my changes. When I do that and then run my quality-checking command; I get a interface with cleared settings. Which is the type of outcome I'm looking for.

For some reason this bug occurs with the resource, nxos_spanning_tree_interface only. I'm unable to get the same outcome that I get with the resource, nxos_physical_interface.

Is this expected or is this a bug? If it's not a bug, is there anything I'm missing in order to properly destroy/clear this setting. I even tried using nxos_rest to delete the object but it never got deleted either.

[Rossnunez]

@danischm can you help with this issue?

[danischm]

There are some objects in the DME object tree that cannot be deleted. This seems to be one of them. We could consider resetting the configuration of the object to some default values during the destroy operation, but this might lead to unexpected results as well, as it might change a configuration the user never intended to change in the first place.

[Rossnunez]

This doesn't make sense to me can you further explain? If I can clear this setting by calling these commands on the cisco switch

config t ; interface eth1/27 ; no spanning-tree port type edge

Then why can't this provider do the same thing?

@SMBurrows @danischm @manofcolombia @JockDaRock