cluster-api-provider-azure
                                
                                 cluster-api-provider-azure copied to clipboard
                                
                                    cluster-api-provider-azure copied to clipboard
                            
                            
                            
                        Remote Peerings are left in a disconnected state instead of being deleted
/kind bug
[Before submitting an issue, have you checked the Troubleshooting Guide?]
What steps did you take and what happened:
given the scenario:
- Cluster is deployed with Capz
- Resource group is owned by Capz
- vnet peerings were specified to be created
- the vnet peerings are to a vnet in a differnet resource group
when the cluster is deleted it will delete the resource group which deletes everything underneath it. however, if any of the vnets are peered with a vnet in a different resource group the other side of the peering will be left in a disconnected state instead of being deleted. At this point redeploying the cluster fails due to the left over peering being stuck in a disconnected state and must be manually cleaned up before being deleted
However, if the resource group is not owned by capz, the reconciler will run through each object inside of the resource group for deletion, in this scenario the remote peerings are successfully deleted
The logic for this may be found at https://github.com/kubernetes-sigs/cluster-api-provider-azure/blob/main/controllers/azurecluster_reconciler.go#L116
What did you expect to happen: When a cluster is deleted, all peerings are cleaned up
Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]
Environment:
- cluster-api-provider-azure version:
- Kubernetes version: (use kubectl version):
- OS (e.g. from /etc/os-release):
/help
@CecileRobertMichon: This request has been marked as needing help from a contributor.
Guidelines
Please ensure that the issue body includes answers to the following questions:
- Why are we solving this issue?
- To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
- Does this issue have zero to low barrier of entry?
- How can the assignee reach out to you for help?
For more details on the requirements of such an issue, please see here and ensure that they are met.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.
In response to this:
/help
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
/assign