mheap
commented
3 months ago Hey @shawnchapla-8451, thanks for raising an issue.
Making the CP ID a configuration setting of the provider itself is an interesting idea. I think from a UX perspective what we have now is the best option, but I agree that changing the CP ID on an existing resource should force a recreation.
Leave it with me and I'll see what we can do
Found through testing that if you create a set of resources with the ID of one control plane (CP) then change that value to another, the provider creates the resources on the new CP while "orphaning" those on the original (lost from Terraform state). I would think that changing the control plane ID attribute would trigger a destroy/create sequence (destroy resources on the first CP before creating on the second).
I recognize that this may be problematic given you can't guarantee modifications to the Terraform code would change the CP for all affected resources, and you could run into an issue e.g. where the CP ID of the service is changed but not that of the related route; destroying the service resource then disassociates the route from an existing service.
Perhaps an alternative solution is to make the CP ID a configuration setting of the provider itself, and you can use provider aliases (each with their own CP ID setting) to manage resources across multiple CPs with the same code base.