[change] Avoid reserved host-route subnets

[krrishnaik]

Host-route subnet division no longer creates an additional reserved subnet
database object for IPv4 /32 and IPv6 /128 rules, while preserving the
existing allocation behavior for multi-address subnet divisions.

Checklist

• I have read the OpenWISP Contributing Guidelines and OpenWISP Anti AI Spam Policy.
• I have manually tested the changes proposed in this pull request.
• I have written new test cases for new code and/or updated existing tests for changes to existing code.
• I have updated the documentation.

Reference to Existing Issue

Fixes #1468.

Description of Changes

When subnet division provisions a host-route subnet (/32 for IPv4 or /128 for IPv6), there is no need to persist a separate reserved subnet because the generated subnet contains only a single host address.

This change updates the allocation logic to avoid creating the additional Reserved Subnet database object for host-route rules, while preserving the existing reserved-subnet behavior for multi-address subnet divisions.

Regression coverage was added for both IPv4 /32 and IPv6 /128 provisioning to verify that the expected child subnet and IP address are created without creating a Reserved Subnet object. The subnet-division documentation was also updated to describe this host-route-specific behavior.

The changes were verified with the full subnet-division test suite and the repository QA checks. Manual end-to-end verification through the local Django admin confirmed that an IPv4 /32 VPN subnet was provisioned as 10.0.0.2/32 with IP 10.0.0.2, while no additional Reserved Subnet object was created.

Screenshot

Before

With the original allocation behavior, provisioning an IPv4 /32 host-route created the expected child subnet along with an additional Reserved Subnet database object.

After

With the updated allocation behavior, provisioning the IPv4 /32 host-route creates the expected child subnet without creating the additional Reserved Subnet database object.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: b5de0b30-989e-4b4b-ba6c-bf28fb1a76c4

📥 Commits

Reviewing files that changed from the base of the PR and between 335c8c1 and 1ddf79a.

📒 Files selected for processing (1)

• openwisp_controller/subnet_division/rule_types/base.py

Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review.

📜 Recent review details

⏰ Context from checks skipped due to timeout. (8)

• GitHub Check: Python==3.10 | django~=5.2.0
• GitHub Check: Python==3.10 | django~=5.1.0
• GitHub Check: Python==3.13 | django~=5.2.0
• GitHub Check: Python==3.11 | django~=5.1.0
• GitHub Check: Python==3.12 | django~=5.1.0
• GitHub Check: Python==3.13 | django~=5.1.0
• GitHub Check: Python==3.11 | django~=5.2.0
• GitHub Check: Python==3.12 | django~=5.2.0

🧰 Additional context used

📓 Path-based instructions (1)

Flag potential security vulnerabilities Flag obvious performance regressions, such as heavy loops, repeated I/O, or unoptimized queries Flag unused or redundant code Flag outdated or incorrect comments/docstrings Ensure new code handles err...

⚙️ CodeRabbit configuration file

Files:

• openwisp_controller/subnet_division/rule_types/base.py

🧠 Learnings (1)

📚 Learning: 2026-02-17T19:13:10.088Z

Learnt from: nemesifier
Repo: openwisp/openwisp-controller PR: 1175
File: openwisp_controller/config/whois/commands.py:0-0
Timestamp: 2026-02-17T19:13:10.088Z
Learning: In reviews for the openwisp/openwisp-controller repository, do not propose changes based on Ruff warnings. The project does not use Ruff as its linter; ignore Ruff-related suggestions and follow the repository’s established linting and configuration rules. This guidance applies to all Python files under the openwisp_controller directory.

Applied to files:

• openwisp_controller/subnet_division/rule_types/base.py

🔇 Additional comments (1)

openwisp_controller/subnet_division/rule_types/base.py (1)

193-193: LGTM!

Also applies to: 207-209, 210-214, 216-218

---

📝 Walkthrough

Walkthrough

get_max_subnet now skips reserved Subnet creation for IPv4 /32 and IPv6 /128 rules. Larger prefixes retain reserved-subnet creation. Tests verify both cases. Documentation describes the updated behavior.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: nemesifier

Merge Risk: ⚪ Minimal · up to 1ddf7

The host-route allocation and reserved-subnet behavior are covered for both IPv4 and IPv6, with no merge-blocking risk identified.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The implementation satisfies #1468. get_max_subnet returns the first host-route child subnet without saving a Reserved Subnet object when the division size equals the address family's maximum pref…
Out of Scope Changes check	✅ Passed	The changed production code, regression tests, and subnet-division documentation directly support #1468. The changes do not show an unrelated feature or unrelated behavior change. The existing multi-a…
Ui Changes, Regression Test, Docs	✅ Passed	The pull request meets all stated custom-check requirements. The behavior changes a user-visible IPAM subnet record, and the supplied PR description includes explicit Before and After screenshots of t…
Title check	✅ Passed	The title uses the required [change] prefix and clearly describes the host-route reserved subnet change.
Description check	✅ Passed	The description includes all required checklist items, issue reference, change details, testing information, documentation updates, and relevant before-and-after screenshots.

---

_{Comment @coderabbitai help to get the list of available commands.}

[coveralls]

coverage: 98.362%. remained the same — krrishnaik:issues/1468-reserved-host-route-subnets into openwisp:master

[krrishnaik]

@coderabbitai full review!

[coderabbitai]

@krrishnaik I will perform a full review of pull request #1481.

✅ Action performed

Full review finished.

[krrishnaik]

Hi @nemesifier,

I’m a little confused about the next step in the process for PR #1481 and wanted to ask for your guidance.

The PR currently has the required approval and all checks are passing, but GitHub shows that the branch is out of date with the base branch. Since I’m not authorized to merge into master, I’m not sure whether I should update my branch or simply leave it as it is and wait for a maintainer to merge it.

I’m honestly a little lost here since this is my first open-source contribution, so it would be really helpful if you could guide me on what I should do next and how this process usually works.

Could you please let me know what you would prefer me to do from here?

Thanks a lot for your guidance and patience!

[openwisp-companion]

Proposed change log entry:

[fix] Avoided reserved host-route subnets #1468

Updated subnet division logic to prevent creating unnecessary reserved
subnet database objects for host-route rules such as IPv4 /32 and IPv6
/128 subnets, while preserving existing behavior for multi-address
subnets.

Fixes #1468

[openwisp-companion]

Hi @krrishnaik,

Thank you for your interest in contributing to OpenWISP.

This pull request has been flagged as invalid because external contributors must target an issue validated by maintainers before requesting review.

Please link this pull request to a validated issue by adding Fixes #ISSUE_NUMBER, Closes #ISSUE_NUMBER, or Related to #ISSUE_NUMBER to the pull request description. The issue may be in this repository or another OpenWISP repository.

If there is no validated issue yet, please open one first and wait for maintainer validation before continuing with this pull request.

An issue is considered validated when it is open, has at least one label, has no invalid or wontfix label, and is assigned to either the OpenWISP Contributor's Board or the OpenWISP Priorities for next releases.

Please refer to the OpenWISP Contributing Guidelines for more information.

Please see the OpenWISP Anti AI Spam Policy.

Feel free to join the OpenWISP dev chatroom to coordinate with the development team.

Pull requests from external contributors that target an unvalidated issue are flagged as invalid and closed automatically if not resolved within 24 hours.

Thank you for your understanding.

[krrishnaik]

Hi @nemesifier,

Thank you for reviewing and merging my first contribution! I’m really happy to have gotten my first OpenWISP contribution merged, and the process has made me even more curious about the project.

Since this was my first open-source contribution, I’m still trying to understand the workflow and how I can improve as a contributor. I’d really appreciate any guidance you can give me on how to approach future issues and contribute more effectively.

I’m also eager to pick up another issue and continue contributing to OpenWISP. Before I do that, I wanted to understand one thing about #1481: after the PR was merged, the openwisp-companion bot added an invalid label and said that the issue was not validated. I found that a little confusing since the PR had already been reviewed and merged. Could you help me understand why that happened and what I should do differently for my next contribution?

I’d really appreciate your guidance, especially since I’m just getting started with open source. Looking forward to contributing more!