Open luisfeliz79 opened 1 year ago
Hi @luisfeliz79 ,
Thank you for taking time to report this issue!
Would you please try to set public_network_access_enabled = false
then apply it before delete the resource?
HI @ms-henglu , this works. If I turn off the public endpoint via the portal or by changing the terraform plan+applying, followed by a destroy, then the destroy operation completes successfully.
Hi @ms-henglu, checking in on the status for this thread?
This is still an issue as doing a destroy operation always fails unless the public network access is disabled as manual step.
Ideally, the module should disable the endpoint before attempting destruction of azurerm_spring_cloud_api_portal.
@luisfeliz79 my name is Ken, PM from Azure Spring Apps. Let me try to clarify this further here. in general, disabling/deleting a managed Tanzu component like API portal here is considered as a serious action which will destroy Tanzu components away from your enterprise tier instances. So to avoid to disable them by mistake on customer side, we put some prerequisites for each kind of Tanzu component to help you/customers take this action carefully. Like for API portal here, to execute a deletion of API portal can be pretty safe if no public endpoint assigned by you or customers since there surely will be no traffic to it. Let me know if you still have comments on it.
Hi @taoxu0903 - the way terraform typically works, and our users expect it to work is that it "declares intended infra state". So when the user adds/modifies/removes a resource from their terraform config they expect terraform to do everything required to get to that state. As such there should be no manual steps required for deletion, and if there is users will unlikely know about it making for a poor ux. If the resource is removed from config then it should be deleted and removed.
as it stands users will remove it, try to apply and it will fail to delete, know they have to restore the config and change this flag, apply, and then remove it from config, and apply again.
I agree with @luisfeliz79 that this is a bug that should be fixed by having the provider update this property before deletion.
Hi @taoxu0903, Ken, completely understand your logic, however, in this case the public endpoint is being enabled automatically, not through a post deployment action. Perhaps a good compromise would be to surface a feature or provider flag that can allow the deletion to complete even if the public endpoint is enabled. This is way is safe by default, but those who need the automation to work, have an option. Thoughts?
about "the public endpoint is being enabled automatically", this is not true actually. for API portal, to expose either the default public endpoint owned by ASA, or binding a custom domain, you need manually do it. By default after enabling API portal only, no endpoint would be exposed. Please double check if you see same behavior on your side.
Got it.... So then to fix this, would the action item be this?
If "public_network_access_enabled" = true as part of an "azurerm_spring_cloud_api_portal" resource then during a destroy operation for "azurerm_spring_cloud_api_portal" the code should automatically disable the public endpoint first, then attempt deletion of the API portal.
This would successfully allow terraform destroy operations to complete successfully and no user interaction or workarounds are needed.
@taoxu0903 FWIW other APIs within Azure will handle this as part of the Delete process, so I'd consider this an API bug since this is configured via a property within the Spring Cloud API Portal resource, rather than something the Provider should need to do?
From the Providers side, users have confirmed they want to destroy the resource via the Terraform Plan/Apply workflow, so from our side this should be part of the regular deletion flow - but (as mentioned above) I'd consider this an API bug that needs to be fixed there, rather than worked around in different clients.
Got your points, guys. I just synced internally with our engineer team and generally we feel it makes sense to add a force deletion flag to allow to delete without removing pre-conditions. I will add it into backlog for overall planning for next sprints.
Is there an existing issue for this?
Community Note
Terraform Version
1.3.7
AzureRM Provider Version
3.38.0
Affected Resource(s)/Data Source(s)
azurerm_spring_cloud_api_portal
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
I expect the apiportal resource to be destroyed successfully
Actual Behaviour
The destruction of the plan is interrupted with the error "Please unassign public endpoint before deleting API Portal."
Steps to Reproduce
Note: You may need to prepare your subscription first, see here:
https://github.com/Azure/azure-spring-apps-reference-architecture/tree/main/terraform#:~:text=az%20provider%20register
terraform init terraform plan -out my.plan terraform apply my.plan
terraform plan -destroy -out my.plan terraform apply my.plan
Note: same behavior when using terraform destroy -auto-approve
Important Factoids
No response
References
No response