[action] [PR:26937] [PrefixListMgr]: Refactor PrefixListMgr to support multiple prefix types via config registry#2280
Merged
Conversation
…pes via config registry
#### Why I did it
Currently PrefixListMgr only supports ANCHOR_PREFIX with hardcoded device-type checks and template references. This refactor makes PrefixListMgr data-driven and extensible, and adds a generic SUPPRESS_PREFIX type for route suppression use cases.
##### Work item tracking
- Microsoft ADO **(number only)**: 37638053
#### How I did it
**Registry refactor (ANCHOR_PREFIX behavior unchanged):**
- Added `PREFIX_TYPE_CONFIG` registry mapping each prefix type to its templates, allowed device types, prefix-list naming lambda, and log labels
- Added `_is_device_allowed()` helper using `(type, subtype)` tuple matching, with `None` = unrestricted
- Refactored `generate_prefix_list_config` to use registry lookup instead of hardcoded checks
- Renamed handler local `prefix_list_name` → `prefix_type` to avoid confusion with `data["prefix_list_name"]`
- Used `metadata.get("subtype", "")` to handle devices without subtype
**SUPPRESS_PREFIX type (new):**
- Added `SUPPRESS_PREFIX` registry entry with `allowed_devices: None` (any device)
- Added `add_suppress_prefix.conf.j2` / `del_suppress_prefix.conf.j2` templates
- In CLI: replaced global `check_spine_router` with per-type `validate_device_for_type`
**constants.yml-driven prefix-list name resolution:**
- Prefix-list names resolved from `constants.yml` (`bgp.prefix_list.<type>.ipv4_name` / `ipv6_name`) with registry lambda as fallback
- Enables downstream repos to override names via `constants.yml` alone
**Backward-compatibility:**
- All 5 existing ANCHOR_PREFIX unit tests pass unchanged
- PrefixListMgr registered on all devices — ANCHOR_PREFIX on non-spine devices logs a warning (no FRR state change; doesn't occur in practice)
- CLI `status` now allowed on any device (read-only)
#### How to verify it
- All 15 unit tests pass (5 existing ANCHOR_PREFIX + 2 registry validation + 5 SUPPRESS_PREFIX + 3 constants override/fallback)
- ANCHOR_PREFIX behavior identical before and after
#### Which release branch to backport (provide reason below if selected)
- [ ] 202305
- [ ] 202311
- [ ] 202405
- [ ] 202411
- [ ] 202505
- [ ] 202511
- [x] 202603
#### Tested branch (Please provide the tested image version)
- [x] SONiC.20251110.19
#### Description for the changelog
Refactor PrefixListMgr to use a data-driven config registry with constants.yml-driven prefix-list name resolution, and add generic SUPPRESS_PREFIX type.
#### Link to config_db schema for YANG module changes
No YANG model changes. Uses existing PREFIX_LIST table:
[Prefix list](https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/doc/Configuration.md#prefix-list)
#### A picture of a cute animal (not mandatory but encouraged)
<img width="491" height="526" alt="枣" src="https://github.com/user-attachments/assets/244cb96f-1b7d-4110-8ba4-92a5a4abcee0" />
Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>
Collaborator
Author
|
Original PR: sonic-net/sonic-buildimage#26937 |
Collaborator
Author
|
/azp run |
8 tasks
|
Azure Pipelines successfully started running 1 pipeline(s). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why I did it
Currently PrefixListMgr only supports ANCHOR_PREFIX with hardcoded device-type checks and template references. This refactor makes PrefixListMgr data-driven and extensible, and adds a generic SUPPRESS_PREFIX type for route suppression use cases.
Work item tracking
How I did it
Registry refactor (ANCHOR_PREFIX behavior unchanged):
PREFIX_TYPE_CONFIGregistry mapping each prefix type to its templates, allowed device types, prefix-list naming lambda, and log labels_is_device_allowed()helper using(type, subtype)tuple matching, withNone= unrestrictedgenerate_prefix_list_configto use registry lookup instead of hardcoded checksprefix_list_name→prefix_typeto avoid confusion withdata["prefix_list_name"]metadata.get("subtype", "")to handle devices without subtypeSUPPRESS_PREFIX type (new):
SUPPRESS_PREFIXregistry entry withallowed_devices: None(any device)add_suppress_prefix.conf.j2/del_suppress_prefix.conf.j2templatescheck_spine_routerwith per-typevalidate_device_for_typeconstants.yml-driven prefix-list name resolution:
constants.yml(bgp.prefix_list.<type>.ipv4_name/ipv6_name) with registry lambda as fallbackconstants.ymlaloneBackward-compatibility:
statusnow allowed on any device (read-only)How to verify it
Which release branch to backport (provide reason below if selected)
Tested branch (Please provide the tested image version)
Description for the changelog
Refactor PrefixListMgr to use a data-driven config registry with constants.yml-driven prefix-list name resolution, and add generic SUPPRESS_PREFIX type.
Link to config_db schema for YANG module changes
No YANG model changes. Uses existing PREFIX_LIST table:
Prefix list
A picture of a cute animal (not mandatory but encouraged)
Signed-off-by: Sonic Build Admin sonicbld@microsoft.com