I'm also interested by this topic. I was looking at this DeallocateIP function and wondering whether we should proceed to implement it + contribute back the change, but I am not sure if there is more context/history around why this was not implemented previously (e.g. a race condition, timing issue, or another concern that we should be aware of).

In our environment we sometimes have extremely small IP pools available (e.g. 3-5 IPs available) so reclaiming those addresses after cluster deletion is going to be important.

Tagging @abhinavnagaraj and @sadysnaat for their input

Thanks folks!

@abhinavnagaraj @sadysnaat : can you please allow me to push a PR to a private branch.

root@LAPTOP-5CC3SOCS:~/goroot/src/github.com/metal3-io/cluster-api-provider-vsphere-static-ip# git push -f --set-upstrea
m origin deleteipclaim_reclaimproj
remote: Permission to spectrocloud/cluster-api-provider-vsphere-static-ip.git denied to acraghav.
fatal: unable to access 'https://github.com/spectrocloud/cluster-api-provider-vsphere-static-ip.git/': The requested URL returned error: 403

@acraghav, is this the error you see when you try to push to your fork ?

@acraghav , @nwoodmsft , apologies for the late response ! Our team has been very busy.

The reason we don't face this issue currently is because we have a wrapper service which generates the m3 IPPool while creating the cluster. So when this cluster is deleted this wrapper service knows that those IPs can be reallocated for the next cluster.

There seems to be an issue while setting the IPClaim's ownerRef as VSphereCluster. But otherwise, on deletion of the parent objects - VSphereCluster/VSphereMachine, the corresponding IPClaims and IPAddresses should be garbage collected.

Thanks @abhinavnagaraj for your feedback. We are taking your latest build and testing our scenario.