fix(network): relax constraints for resizing dynamic range reservations

[bryanfraschetti]

When an IP is allocated inside a dynamic range reservation, the validation performed during a resize sees the range as discontinuous, since an allocated IP splits the available space into separate contiguous blocks. As a result, both shrinking and expanding the reservation are rejected with "Requested dynamic range conflicts with an existing IP address or range", even when the requested change is otherwise valid.

This commit addresses the issue by comparing the requested range against the previously persisted range and requiring only the newly added segments (i.e., the expanded portions) to be contained within an unused range. Pure shrinks add no segments and are always allowed.

Resolves LP:2143090

[maas-lander]

Check where you would like a Mattermost message to be sent to when CI completes and this PR is merged

• Direct message
• ~maas

[Copilot]

Pull request overview

This PR fixes validation for resizing existing dynamic IP ranges when there are already allocated IPs inside the current range, which previously caused the “Requested dynamic range conflicts…” error by treating the range as discontinuous.

Changes:

• Updates dynamic range overlap validation to permit resizing when only the newly-added segments are within unused space.
• Adds regression tests ensuring an existing dynamic range can shrink/expand even with an allocated IP inside the original range.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/maasserver/models/iprange.py	Adjusts overlap/duplicate validation to allow certain dynamic-range resizes with in-range allocations.
src/maasserver/models/tests/test_iprange.py	Adds tests covering shrink/expand of an existing dynamic range when an IP inside it is allocated.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[tanzin8r]

Thanks for the fix.

Implementation

• Consider caching the original start, end, and subnet when the model is loaded from the database using from_db, so validation does not need an extra query on every clean().
• The same overlap check exists in the v3 ipranges API. I can help with that part if you want.
• When the range is moved to another subnet, the resize exception should not apply. Use full validation on the new subnet instead.

Testing

I ran additional cases on top of the PR tests, including the subnet-change guard.

Expected to pass on resize:

1. Shrink end with lease inside pool
   Range 10–50, lease at .30, end changed to .49.
   Expected: clean() and save() succeed. Only addresses at the tail are removed; nothing new is claimed.

2. Expand end with lease inside pool
   Range 10–50, lease at .30, end changed to .60.
   Expected: succeed. Only 51–60 is new and should be free. The lease inside the old range should not block this.
   I also checked on master without the fix: this fails with error from the bug report. With the PR it passes.

3. Shrink start with lease inside pool
   Range 10–50, lease at .30, start changed to .15.
   Expected: succeed. Same idea as shrinking the end, but on the start boundary.

4. Expand start into free space on the left
   Range 20–50, lease at .30, start changed to .10 with free space below 20.
   Expected: succeed. Only the new strip on the left must be free.

5. Shrink end so lease ends up outside pool
   Range 10–50, lease at .30, end changed to .25.
   Expected: succeed. The lease is no longer inside the range after the change.

All of the above passed.

Expected to fail on resize:

1. Expand end over a lease outside the old pool
   Range 10–20, lease at .25, end changed to .30.
   Expected: rejected. The new strip 21–30 includes an address that is already in use.

2. Expand start over a lease outside the old pool
   Range 20–50, lease at .15, start changed to .10.
   Expected: rejected. The new strip 10–19 includes an address that is already in use.

3. Move pool to another subnet over a busy IP
   Range moved to another subnet where the new bounds overlap a busy address.
   Expected: rejected. The resize exception should not apply; validation should run on the new subnet.

4. Create new pool spanning an already-assigned IP
   New dynamic range 10–50 while .30 is already assigned on the subnet.
   Expected: rejected. The fix is for editing an existing range, not for creating one over a split gap.

All of the above were rejected as expected.

[tanzin8r]

Nice work on the caching and subnet guard! Could you rebase onto upstream master when you get a chance? Some of the tests were failing are fixed there now.
On tests, I think you have the main bug covered already. The ones I would still add are the failure cases: expanding over a busy IP just outside the old pool on both start and end, a full clean() test when moving the range to another subnet that already has a clash, and one create-path test to make sure new ranges still get rejected if they span an already-assigned IP.

On v3 side, the logic lives in src/maasapiserver/v3/api/public/models/requests/ipranges.py inside to_builder(), called from update_fabric_vlan_subnet_iprange() in the handler. Subnet move is less of an issue there since the URL pins the subnet, but the resize-with-lease-inside-pool bug will still show up. We can create a seperate PR for that.

[bryanfraschetti]

Thanks for the review!

Good idea to add tests for the failure cases. I just rebased and added some tests to cover the ones you mentioned: resizing, moving, or creating dynamic ranges over a busy IP.

I'll look into the v3 API and put up changes in a separate PR. Thank you for the pointers regarding that

[tanzin8r]

lgtm. Thank you for the edits. Just one last test to make this concrete.

    def test_modify_existing_dynamic_range_can_expand_start_with_allocated_ip(
        self,
    ):
        subnet = make_plain_subnet()
        iprange = IPRange(
            subnet=subnet,
            type=IPRANGE_TYPE.DYNAMIC,
            start_ip="192.168.0.20",
            end_ip="192.168.0.50",
        )
        iprange.save()
        factory.make_StaticIPAddress(
            subnet=subnet,
            alloc_type=IPADDRESS_TYPE.AUTO,
            ip="192.168.0.30",
        )
        iprange.start_ip = "192.168.0.10"
        iprange.clean()
        iprange.save()

[tanzin8r]

+1

[r00ta]

questions inline

[r00ta]

+1, thank you!

[r00ta]

@bryanfraschetti there are test failures

[bryanfraschetti]

Thanks @r00ta! I fixed the failing tests by rebasing