feat(schema): number pool ranges and allocation scope

[polmichel]

Why

Infrahub 1.12 lets a number pool allocate from several weighted ranges, and divide its space by an allocation scope. A user declares both in a schema file, so neither is usable until the generated write models accept them and the generated read models return them.

The four changed modules are generated from Infrahub's own core schema definitions by invoke backend.generate, which writes into this submodule. The definitions they come from live on the Infrahub branch feature-number-pools-1.12 and are not on Infrahub develop yet.

Non-goal: this branch adds no behaviour of its own. Allocation across ranges and the scope check are implemented in the Infrahub backend.

What changed

Behavioural changes:

• A schema file can declare parameters.ranges on a NumberPool attribute: a list of start/end ranges with an optional weight. Until now the schema load endpoint dropped the value, because the write models set extra="ignore".
• A schema file can declare parameters.allocation_scope: the fields of the kind that divide the pool's space.
• start_range and end_range become optional and carry no default. A NumberPool attribute declared without any range is submitted as such, instead of receiving 1 to 9223372036854775807. Both stay accepted, deprecated in favour of ranges.
• The schema read endpoint returns ranges and allocation_scope.
• infrahub_sdk.protocols exposes CoreNumberPoolRange and CoreNumberPoolRangeSync, and CoreNumberPool carries ranges and allocation_scope.

What stayed the same: no hand-written SDK module changed. The four changed modules are generated, and infrahub_sdk/protocols_generator/ is untouched.

Commits:

• 1c3277b — regenerate protocols for the number pool range kind
• 1bd89c8 — accept the number pool allocation_scope in the generated schema models

How to review

Reviewing the generated modules on their own says little. The source of truth is backend/infrahub/core/schema/definitions/core/resource_pool.py and backend/infrahub/core/schema/attribute_parameters.py on the Infrahub branch feature-number-pools-1.12.

Three consumers in the Infrahub backend read these models directly:

• backend/infrahub/api/schema.py — SchemaLoadAPI subclasses InfrahubSchemaWrite.
• backend/infrahub/schema/read_schema.py — build_read_schema projects onto BaseNodeSchemaRead.
• backend/infrahub/core/schema/write_json_schema.py — reads READ_ONLY_FIELDS and InfrahubSchemaWrite.

How to test

uv run pytest tests/unit/test_schema_offline_validation.py

From an Infrahub checkout pinning this branch, the generated files must match what the branch's definitions produce:

invoke backend.validate-generated

Impact & rollout

• Backward compatibility: start_range and end_range are still accepted. Dropping their defaults changes what reaches the server for a NumberPool attribute declared without any range.
• Deployment notes: [CLAUDE RECOMMENDED – based on the submodule pins read from git ls-tree and the validate_generated task in tasks/backend.py] This branch should be merged in the same window as the Infrahub branch feature-number-pools-1.12, not before it. Infrahub develop pins SDK commit 2ac1179 explicitly, so merging here does not break it immediately; but the first bump of that pin to the new infrahub-develop tip would fail validate_generated, because develop's core models do not declare these fields.

Checklist

• Tests added/updated
• Changelog entry added
• External docs updated (if user-facing or ops-facing change)
• Internal .md docs updated

---

Assisted-by: opsmill-dev-pr 0.2.0

🤖 Generated with Claude Code

---

Summary by cubic

The generated SDK models now accept parameters.ranges and parameters.allocation_scope on NumberPool attributes, so a schema file can declare several weighted ranges and divide a pool's space by kind fields.

• start_range/end_range become optional and deprecated; a NumberPool declared without any range is submitted as such, instead of receiving a default 1 to 9223372036854775807.
• The schema read endpoint returns ranges and allocation_scope, and infrahub_sdk.protocols gains CoreNumberPoolRange/CoreNumberPoolRangeSync.
• The four changed modules are generated from Infrahub's core schema definitions; no hand-written SDK code changed.

Rollout

• Merge alongside the Infrahub branch feature-number-pools-1.12, not before it. A subsequent pin bump on Infrahub develop would fail validate_generated because develop's core models do not declare these fields.

^{Written for commit 1bd89c8. Summary will update on new commits.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

@@                 Coverage Diff                  @@
##           infrahub-develop    #1412      +/-   ##
====================================================
- Coverage             87.14%   86.82%   -0.32%     
====================================================
  Files                   153      152       -1     
  Lines                 16493    14775    -1718     
  Branches               2417     1982     -435     
====================================================
- Hits                  14372    12829    -1543     
+ Misses                 1493     1382     -111     
+ Partials                628      564      -64     

Flag	Coverage Δ
integration-tests	42.36% <55.00%> (-1.25%)	⬇️
python-3.10	60.91% <55.00%> (-1.14%)	⬇️
python-3.11	60.91% <55.00%> (-1.14%)	⬇️
python-3.12	60.91% <55.00%> (-1.14%)	⬇️
python-3.13	60.90% <55.00%> (-1.15%)	⬇️
python-3.14	60.91% <55.00%> (-1.14%)	⬇️
python-filler-3.12	22.94% <45.00%> (+0.37%)	⬆️

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

Files with missing lines	Coverage Δ
infrahub_sdk/protocols.py	100.00% <100.00%> (ø)
infrahub_sdk/schema/generated/contract.py	100.00% <ø> (ø)
infrahub_sdk/schema/generated/read.py	100.00% <100.00%> (ø)
infrahub_sdk/schema/generated/write.py	99.40% <100.00%> (+0.02%)	⬆️

... and 15 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.