nagaboinaramgopal commented on PR #14133: URL: https://github.com/apache/cloudstack/pull/14133#issuecomment-5682909252
Thanks for the fix and the tests. I tried it on a KVM zone with the steps from #14068 (VPC offering with the Firewall service, a tier with a VM, a public IP with a port forwarding and a firewall rule, then remove the VM and the tier). Without the change, deleting the VPC fails with `Cannot invoke "com.cloud.network.Network.getId()" because "network" is null`, with the same stack as in #14068. Releasing the public IP after removing the tier, while keeping the VPC, fails with the same NPE. In both cases the IP still has `network_id` set to the removed tier and stays in Releasing. With the change, both work. The VPC is deleted, and the released IP goes back to Free with `network_id` and `vpc_id` cleared. A VPC that was already stuck from the earlier attempt could also be deleted with the change in place. I was curious where the stale id comes from. On tier removal, `NetworkOrchestrator` calls `VpcManager.unassignIPFromVpcNetwork` for VPC IPs, and that method returns early when `isIpAllocatedToVpc(ip)` is true. With the Firewall service in the VPC offering, a public IP with a firewall rule matches that check (`firewallDao.listByIp` is not empty), so the IP keeps pointing at the removed tier. One thing I noticed: after releasing the IP with the VPC kept, the IP is still configured on the VPC router's public interface, with an iptables rule for it, since no ipassoc is sent in the new path. As the IP is Free again, it could be given to another network while the old router still holds it. Would it make sense to apply the association through the VPC in that case, since the router is still there, or to clear the association when the tier is removed so the normal release path runs? Either way, keeping the guard as a safety net sounds good to me. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
