network: handle missing network when releasing public IP

[xujiantop-crypto]

Fixes #14068

During VPC teardown, a public IP can retain its associated network ID after the tier's network record has been deleted. disassociatePublicIpAddress passes the missing network to applyIpAssociations, which dereferences it and aborts VPC deletion with a NullPointerException.

Resolve the associated network before choosing the release path. When the network no longer exists, a releasing IP follows the existing quarantine and unassignment path. The association path continues to be used when the network exists.

The regression test supplies a non-null associated network ID whose DAO lookup returns null while the VPC still exists. It verifies successful release, quarantine, IP unassignment, VPC provider cleanup, annotation cleanup and lock release, without calling applyIpAssociations. Additional tests cover successful and failed associations when the network exists, and prevent repeated quarantine/unassignment of an already free IP when the network is missing.

This targets 4.22 in accordance with the contribution guide's release-branch policy for bug fixes; the affected code is also present there.

Validation

• The initial missing-network regression test reproduced NullPointerException on the unfixed 4.22 base.
• With the fix and expanded coverage, the complete IpAddressManagerTest passes: 30 tests, 0 failures/errors/skips. All 25 selected reactor modules succeed, with 0 Checkstyle violations (JDK 11).
• git diff --check passes.

The Maven download plugin could not retrieve the system VM checksum file in this environment. I downloaded the unmodified official https://download.cloudstack.org/systemvm/4.22/sha512sum.txt to engine/schema/dist/systemvm-templates/sha512sum.txt and ran:

mvn -B -pl server -am -Dtest=IpAddressManagerTest -Dsurefire.failIfNoSpecifiedTests=false -Ddownload.plugin.skip=true test

Only the redundant download was skipped; compilation, Checkstyle and the selected tests ran. No build configuration changes are included.

For an environment-level check, follow the steps in #14068: create a VPC offering with firewall service enabled, deploy a tier and VM, apply a public-IP firewall rule, remove the VM and tier, then destroy the VPC. The VPC should be removed without the missing-network exception and the public IP should be released. This full VPC scenario has not been run locally.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 17.94%. Comparing base (b9a5977) to head (8903273).
⚠️ Report is 10 commits behind head on 4.22.

Additional details and impacted files

@@            Coverage Diff            @@
##               4.22   #14133   +/-   ##
=========================================
  Coverage     17.94%   17.94%           
- Complexity    16145    16151    +6     
=========================================
  Files          5928     5928           
  Lines        535174   535176    +2     
  Branches      65494    65495    +1     
=========================================
+ Hits          96017    96057   +40     
+ Misses       428228   428181   -47     
- Partials      10929    10938    +9     

Flag	Coverage Δ
uitests	4.02% <ø> (ø)
unittests	19.02% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nagaboinaramgopal]

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.