Hi Patrick Nick
Thank you for sharing the details of the issue you're facing with the VNET deletion and the lingering Service Association Link (SAL).
It seems you've already tried several approaches without success. Based on similar cases, here are a few additional workarounds that may help resolve the issue:
1.Recreate the GitHub Resource in a New Subnet:
- Create a new subnet in the same VNET.
- Recreate the GitHub.Network/networkSettings resource and delegate it to the new subnet.
- Once it's active, try to reassign the original subnet to it, then disconnect it properly.
2. To delete this SAL from your end,
- Create App Service Plan with the same name as the deleted one
- Create App Service with the same name as the deleted one
- Link App Service with the VNET subnet
- Disconnect VNet from App Service -> Networking -> VNet integration -> Disconnect
- Delete subnet
- Then delete the App Service.
- Delete network profiles: if there are any lingering network profiles tied to your subnet, you need to delete them. Use the Azure CLI with the command:
-
Replaceaz network profile delete --resource-group <resource-group-name> --name <network-profile-name>
<resource-group-name>
and<network-profile-name>
with your actual resource group and network profile names. - Delete the Service Association Link: If the previous steps don’t work, you can attempt to delete the Service Association Link using the Azure CLI. Here's the command:
az resource delete --ids /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<subnet-name>/providers/Microsoft.ContainerInstance/serviceAssociationLinks/default --api-version 2018-10-01
Make sure to replace the placeholders with your actual subscription ID, resource group, VNET name, and subnet name.
Reason for this Error: The VNET integration feature must set locks on subnets in the Network Resource Provider, we set these locks by putting a structure called a Service Association Link(SAL) onto the Subnet,
Is there a way to get out of this situation? Also, how can I avoid it in future?
In your Terraform configuration, ensure the subnet delegation is removed before destroying the subnet.- Always disconnect the subnet from the service before deleting the service.
I hope the above steps help, if you need any suggestions from GitHub try to contact the GitHub support team for the assistance.