nagaboinaramgopal opened a new pull request, #14217: URL: https://github.com/apache/cloudstack/pull/14217
Description An isolated guest network allocates guest IPs from the whole CIDR, so there is no way to reserve part of the address space or keep the DHCP pool to a sub-range. createNetwork already takes startip/endip, but NetworkServiceImpl only uses them for shared networks. This stores the start and end IP on an isolated network as a DHCP range, in two new networks columns dhcp_start_ip/dhcp_end_ip, validated to be within the network CIDR, in order, and not to include the gateway. NetworkModelImpl.getAvailableIps then restricts the guest IP pool to that range when it is set; without one the whole CIDR is used, so existing networks are unaffected. The dnsmasq config on the VR is unchanged: for an isolated network it serves the host entry CloudStack writes for the IP it allocated, so constraining the allocation is enough and no system VM template change is needed. The range is returned by listNetworks as startip and endip. Creating an isolated network with a range needs gateway and netmask passed too (already enforced by createNetwork), so the CIDR is deterministic. The create form shows the start and end IP fields once a gateway is entered, and the network details tab shows the range on an existing network, so the whole flow is usable from the UI. Fixes: #12661 Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [x] Enhancement (improves an existing feature and functionality) - [ ] Cleanup (Code refactoring and cleanup, that may add test cases) - [ ] Build/CI - [ ] Test (unit or integration test code) Feature/Enhancement Scale or Bug Severity Feature/Enhancement Scale - [ ] Major - [x] Minor Screenshots (if appropriate): <img width="1400" height="1280" alt="dhcp-create-form" src="https://github.com/user-attachments/assets/1e749381-4d38-4360-a691-6331528e3a56"; /> <img width="1400" height="760" alt="dhcp-vms-in-network" src="https://github.com/user-attachments/assets/bf89fb4e-59df-4128-b5bd-a070d5710dc2"; /> Isolated network detail showing the DHCP range, and the deployed VMs leased inside it. How Has This Been Tested? Unit tests in server, 101 green. NetworkModelImplTest adds two for getAvailableIps: the pool is restricted to the range when set, and is the whole CIDR (minus the gateway) when it is not. NetworkServiceImplTest adds five for the validation: a valid range is stored, the end defaults to the start, and a range outside the CIDR, a start greater than the end, or a range that includes the gateway are each rejected. DatabaseUpgradeCheckerTest is green with the schema change. The two changed UI files pass eslint clean. Manually on a KVM advanced zone. Created an isolated network with gateway 10.99.99.1, netmask /24 and a DHCP range 10.99.99.10-10.99.99.20, confirmed listNetworks returned that range, then deployed three VMs on it. All three leased inside the range (10.99.99.14, .15, .19), where without the change they would draw from the whole /24. How did you try to break this feature and the system with this change? - Range outside the CIDR, reversed range, and a range covering the gateway are all rejected at create time. - A network created without a range still allocates from the whole CIDR, so existing networks and shared networks are unchanged. - Deployed several VMs against an 11-address range and confirmed each landed inside it. -- 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]
