Skip to content

fix(network): 3.8 relax constraints for resizing dynamic range reservations - #560

Open
bryanfraschetti wants to merge 1 commit into
canonical:3.8from
bryanfraschetti:3.8_bpo_fix_dynamic_range_resizing
Open

bryanfraschetti wants to merge 1 commit into
canonical:3.8from
bryanfraschetti:3.8_bpo_fix_dynamic_range_resizing

Conversation

@bryanfraschetti

@bryanfraschetti bryanfraschetti commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

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

(cherry picked from commit 8e8c3f6)

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[maas-code-reviewer review]

LLM-generated review from https://github.com/canonical/maas-code-reviewer.
Intended to assist a human reviewer, not replace one — suggestions may be
incorrect, please verify before acting.

The logic for calculating and verifying newly added segments properly accounts for all resizing and shifting scenarios. This nicely resolves the issue of dynamic range modifications failing when the range already contains active IPs.

I've spotted a minor typing issue in one of the tests that currently works by coincidence due to an early return, but could crash if the function's internal flow is changed. Otherwise, great work!

unused = other_subnet.get_ipranges_available_for_dynamic_range(
exclude_ip_range_id=iprange.id
)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The _is_existing_dynamic_range_resize_allowed method expects start_ip and end_ip to be of type IPAddress (which has a .version attribute), but iprange.netaddr_iprange.first and .last return integers. Although this test passes because the method currently returns False early (since subnet_id changed), it would crash with an AttributeError on start_ip.version if the early returns were ever bypassed or refactored. Consider passing IPAddress(iprange.start_ip) and IPAddress(iprange.end_ip) instead.

if loaded_values.get("subnet_id") != self.subnet_id:
return False

existing_start_ip = loaded_values.get("start_ip")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: existing_start_ip and existing_end_ip are reused here for the IPAddress objects, changing their type from string. It might be slightly cleaner and less prone to confusion to name the string variables differently (e.g. loaded_start_ip) or parse them directly.

@bryanfraschetti bryanfraschetti changed the title fix(network): relax constraints for resizing dynamic range reservatio… fix(network): relax constraints for resizing dynamic range reservations Aug 21, 2026
@bryanfraschetti bryanfraschetti changed the title fix(network): relax constraints for resizing dynamic range reservations fix(network) 3.8: relax constraints for resizing dynamic range reservations Aug 21, 2026
@bryanfraschetti bryanfraschetti changed the title fix(network) 3.8: relax constraints for resizing dynamic range reservations fix(network): 3.8 relax constraints for resizing dynamic range reservations Aug 21, 2026
@skatsaounis skatsaounis added bug blocked do not merge this 3.8 labels Aug 24, 2026
…ns (canonical#280)

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
@bryanfraschetti
bryanfraschetti force-pushed the 3.8_bpo_fix_dynamic_range_resizing branch from e2e74be to e20a3ee Compare September 10, 2026 17:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3.8 blocked do not merge this bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants