meraki_networks_switch_access_policies destroy fails because meraki_devices_switch_ports delete is no-op

[joekohlsdorf]

Describe the bug

• Create meraki_networks_switch_access_policies

  resource "meraki_networks_switch_access_policies" "this_switch_access_policy_example" {
  network_id         = "XXX"
  
  name               = "example"
  host_mode          = "Single-Host"
  access_policy_type = "Hybrid authentication"
  dot1x = {
  control_direction = "inbound"
  }
  increase_access_speed = true
  radius = {
  critical_auth = {
    data_vlan_id        = 10
    suspend_port_bounce = false
    voice_vlan_id       = null
  }
  failed_auth_vlan_id        = 10
  re_authentication_interval = null
  }
  radius_accounting_enabled          = false
  radius_coa_support_enabled         = true
  radius_group_attribute             = ""
  radius_servers                     = [{
  host   = "192.168.1.2"
  port   = 1812
  secret = "<-blanked->"
  }]
  radius_testing_enabled             = true
  url_redirect_walled_garden_enabled = false
  voice_vlan_clients                 = false
  }

• Create meraki_devices_switch_ports referencing the policy

  resource "meraki_devices_switch_ports" "this_switch_port" {
  serial                    = "XXX"
  
  name                      = "1"
  access_policy_type        = "Custom access policy"
  access_policy_number      = meraki_networks_switch_access_policies.this_switch_access_policy_example.access_policy_number
  type                      = "access"
  vlan                      = 1
  port_id                   = 1
  }

Now try to run terraform destroy, you'll get the following response from the API when trying to destroy the access policy after the switch port is destroyed:

{
    "errors": [
       "This access policy is in use by 1 port. An access policy can only be removed if it is not in use."
    ]
}

Expected behavior destroy on a switch port should not be a no-op, instead some kind of default configuration which doesn't depend on any other resources is restored. This could also be a security issue because users of the provider might expect access policies to be removed from ports when the ports are destroyed.

A user should not be expected to reconfigure the switch ports before being able to destroy a network.

Environment (please complete the following information):

• Terraform version: 1.9.6
• Meraki provider version: 1.47.0
• OS Version: Debian 12

[fmunozmiranda]

Hi @joekohlsdorf , could you pass us the provider debug

[obrigg]

Hi Joe, The Meraki Terraform Provider is replicating the behavior of our API operations. As you noticed, a requirement for deleting an access policy is having no ports associated with that policy. We try to avoid breaking changes in our API behavior. When we start planning version 2 of Dashboard API (some time in the future - no dates yet), these kind of behavior changes will be taken into consideration.

Removing a port's association with an access policy can be done using meraki_devices_switch_ports:

resource "meraki_devices_switch_ports" "this_switch_port" {
  serial                    = "XXX"
  access_policy_type        = "Open"
  port_id                   = 1
}

[joekohlsdorf]

Hi @obrigg, In my opinion the current Dashboard API is sufficient, you could give users optional configuration parameters to specify what should be done with the configuration of the ports on destroy. An example provider which does this is terracurl, it isn't pretty but it works and it's definitely better than having to change the configuration before being able to destroy a network.

[obrigg]

Thank you for the feedback. I will make sure the relevant team is aware of it. Does this answer your question about the current behavior?

[fmunozmiranda]

Closed due inactivity.