Automatically generated default RF profiles can't be managed by Terraform

[joekohlsdorf]

When a new network is created, Meraki automatically creates two Wireless RF profiles: Basic Indoor Profile, Basic Outdoor Profile

These profiles can be modified from the Dashboard UI but they can't be managed from the Terraform provider.

It might be possible to manually import these but this workaround is not viable for the following reasons:

• Automatically created profiles can't be deleted. If I terraform import them then I also have to terraform state rm them if I want to terraform destroy the whole network.
• With manual terraform import it is not possible create multiple networks in one terraform apply

Why do I need this if I could just create a new default profile?

If I set is_indoor_default or is_outdoor_default to true on a new meraki_wireless_rf_profile then there is no way to terraform destroy this resource.
The API returns the Cannot delete a default profile. error.

I don't see how this second problem could be resolved from the provider side without changing the API.
Changing the default profile should be a separate API endpoint and it should automatically revert to the automatically generated undeletable profiles when unsetting it.
However, this would not resolve all problems because APs have to be reassigned to the new default, the profile can't be deleted if APs still have the profile assigned to them. And Terraform doesn't necessarily have to manage this assignment, APs get assigned the default profile when they are added to the network. The Dashboard UI automatically reassigns all APs when modifying the default profile but the API does not.

[danischm]

Agree, this is mostly something that would need to be addressed at the API layer. We could look at silently ignoring errors when destroying a resource managing the default profile.

[joekohlsdorf]

We could look at silently ignoring errors when destroying a resource managing the default profile.

Can you explain a little more what you have in mind?
The API returns a 400 if you attempt to destroy a resource which is the default profile so ignoring this error doesn't achieve anything.
Ignoring the error and removing the resource from Terraform state while keeping it as-is is on the API side is arguably worse because then you have dangling config. I know that the provider has this behavior in several places but to me this is always a bug because it breaks the principle of idempotency.

[danischm]

I was specifically referring to the default RF profiles (Basic Indoor Profile, Basic Outdoor Profile). You could then import, modify and destroy them (no-op).

[danischm]

Longer term we might implement a provider scoped allow_existing_on_create opt-in flag, allowing one to manage existing objects without having to import them first. For example, you could then define a resource targeting the "Basic Indoor Profile" and if it already exists, on creation it would update the existing object instead of creating a new one, ie. PUT instead of POST.

[joekohlsdorf]

That would be an option but ideally a user of the provider should be able to change their settings without having to import them manually.

Since these resources can't be deleted they are no different than some organization level configuration setting.

[danischm]

Yes, I guess this would be addressed with my second comment. We could also look at adding an additional singleton resource to manage the default profiles (only GET/PUT).