Conversation
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="tests/unit/tasks/conductor/sonic/test_config_generator_bgp_vlan_vrf.py" line_range="758-772" />
<code_context>
+# ---------------------------------------------------------------------------
+
+
+@pytest.fixture
+def vrf_config():
+ return {
+ "VRF": {},
+ "VLAN": {},
+ "VLAN_INTERFACE": {},
+ "BGP_GLOBALS_AF": {},
+ "BGP_GLOBALS_ROUTE_ADVERTISE": {},
+ "BGP_GLOBALS": {},
+ "VXLAN_TUNNEL": {},
+ "VXLAN_EVPN_NVO": {},
+ "VXLAN_TUNNEL_MAP": {},
+ "INTERFACE": {},
+ "PORTCHANNEL_INTERFACE": {},
+ }
+
</code_context>
<issue_to_address>
**suggestion (testing):** Initialize ROUTE_REDISTRIBUTE in vrf_config fixture to make the intent explicit
`TestAddVrfConfiguration.test_vrf_with_vni_full_config` asserts that `"vrfStorage|connected|bgp|ipv4" in vrf_config["ROUTE_REDISTRIBUTE"]`, but the fixture doesn’t define `"ROUTE_REDISTRIBUTE"`. The test currently depends on `_add_vrf_configuration` to create this key. Initializing `"ROUTE_REDISTRIBUTE": {}` in the `vrf_config` fixture would make the test more explicit and its failures less dependent on implementation side effects.
```suggestion
@pytest.fixture
def vrf_config():
return {
"VRF": {},
"VLAN": {},
"VLAN_INTERFACE": {},
"BGP_GLOBALS_AF": {},
"BGP_GLOBALS_ROUTE_ADVERTISE": {},
"BGP_GLOBALS": {},
"VXLAN_TUNNEL": {},
"VXLAN_EVPN_NVO": {},
"VXLAN_TUNNEL_MAP": {},
"INTERFACE": {},
"PORTCHANNEL_INTERFACE": {},
"ROUTE_REDISTRIBUTE": {},
}
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
berendt
force-pushed
the
gh2223
branch
3 times, most recently
from
8aa1b24 to
6096e3d
Compare
ideaship
added a commit
that referenced
this pull request
May 28, 2026
The SONiC config generator owns config_db.json in full: it generates the file from NetBox data and hardcoded SONiC policy, and operators must not make manual adjustments to it. This ownership model was implicit and undocumented, so each PR touching the generator relitigated which sections it owns (surfaced in review of #2279 and #2290). Document the model in the generate_sonic_config() docstring as whole-file ownership: the generator overwrites every section it manages, and no sections pass operator edits through unchanged. Note the two fields the generator does not itself emit and instead inherits from the device's image-provided base config (the DEVICE_METADATA localhost device attributes and the DATABASE schema VERSION); these come from the image, not from operator hand-edits. Bring the code into line with the documented model: - Rebuild owned tables from scratch instead of overwriting only the entries touched in the current run. generate_sonic_config() deep- copies the base config and most helpers assign only the keys they currently generate, so an entry removed from NetBox but still present in config_db.json (e.g. an old VLAN_MEMBER, BGP_GLOBALS VRF, or VXLAN_TUNNEL_MAP) survived regen as stale, active config. Drop the content of every owned table up front (OWNED_TABLE_KEYS: every generated table except the inherited DEVICE_METADATA and VERSIONS) so only regenerated entries remain. - BGP_GLOBALS['default'] was written with key-level updates that merged into any pre-existing entry, so operator fields survived regen. Replace the entry wholesale when a primary IP is present, like every other generated VRF. - STATIC_ROUTE merged the management default route into the dict loaded from config_db.json, so pre-existing routes (e.g. an operator's custom blackhole or VRF route) survived regen. Clearing the owned tables now drops them before the management route is written. Add tests pinning the model. Illustrative helper tests (test_config_generator_ownership.py) show that _add_vrf_configuration and _add_vlan_configuration replace BGP_GLOBALS[vrf], VLAN entries and ROUTE_REDISTRIBUTE keys wholesale. Orchestrator tests (test_config_generator_orchestrator.py) assert that pre-existing BGP_GLOBALS['default'] fields, STATIC_ROUTE entries, and stale owned-table entries are dropped on regen while DEVICE_METADATA and VERSIONS survive. AI-assisted: Claude Code Signed-off-by: Roger Luethi <luethi@osism.tech>
ideaship
added a commit
that referenced
this pull request
May 29, 2026
The SONiC config generator owns config_db.json in full: it generates the file from NetBox data and hardcoded SONiC policy, and operators must not make manual adjustments to it. This ownership model was implicit and undocumented, so each PR touching the generator relitigated which sections it owns (surfaced in review of #2279 and #2290). Document the model in the generate_sonic_config() docstring as whole-file ownership: the generator overwrites every section it manages, and no sections pass operator edits through unchanged. Note the two fields the generator does not itself emit and instead inherits from the device's image-provided base config (the DEVICE_METADATA localhost device attributes and the DATABASE schema VERSION); these come from the image, not from operator hand-edits. Bring the code into line with the documented model: - Rebuild owned tables from scratch instead of overwriting only the entries touched in the current run. generate_sonic_config() deep- copies the base config and most helpers assign only the keys they currently generate, so an entry removed from NetBox but still present in config_db.json (e.g. an old VLAN_MEMBER, BGP_GLOBALS VRF, or VXLAN_TUNNEL_MAP) survived regen as stale, active config. Drop the content of every owned table up front and only regenerated entries remain. OWNED_TABLE_KEYS is composed from two named sub-categories: the scaffolded-owned tables (every scaffold key except the inherited DEVICE_METADATA and VERSIONS, created up front via setdefault) and the on-demand owned tables (ROUTE_REDISTRIBUTE, the SNMP_* tables and SYSLOG_SERVER, which helpers assign only when NetBox carries their data). - BGP_GLOBALS['default'] was written with key-level updates that merged into any pre-existing entry, so operator fields survived regen. Replace the entry wholesale when a primary IP is present, like every other generated VRF. - STATIC_ROUTE merged the management default route into the dict loaded from config_db.json, so pre-existing routes (e.g. an operator's custom blackhole or VRF route) survived regen. Clearing the owned tables now drops them before the management route is written. Add tests pinning the model. Illustrative helper tests (test_config_generator_ownership.py) show that _add_vrf_configuration and _add_vlan_configuration replace BGP_GLOBALS[vrf], VLAN entries and ROUTE_REDISTRIBUTE keys wholesale. Orchestrator tests (test_config_generator_orchestrator.py) assert that pre-existing BGP_GLOBALS['default'] fields, STATIC_ROUTE entries, and stale owned-table entries are dropped on regen while DEVICE_METADATA and VERSIONS survive. The ownership tests also pin the table-classification taxonomy: that the scaffold set partitions into scaffolded-owned and inherited tables, that owned and inherited tables are disjoint, that OWNED_TABLE_KEYS has no duplicates, and that the scaffolded-owned and on-demand owned sets do not overlap. Most of the taxonomy holds by construction (OWNED_TABLE_KEYS is derived), so these checks exist to fail when the hand-written INHERITED_TABLE_KEYS or ON_DEMAND_OWNED_TABLE_KEYS literals are edited in a way that would silently break the model. AI-assisted: Claude Code Signed-off-by: Roger Luethi <luethi@osism.tech>
ideaship
added a commit
that referenced
this pull request
May 29, 2026
The SONiC config generator owns config_db.json in full: it generates the file from NetBox data and hardcoded SONiC policy, and operators must not make manual adjustments to it. This ownership model was implicit and undocumented, so each PR touching the generator relitigated which sections it owns (surfaced in review of #2279 and #2290). Document the model in the generate_sonic_config() docstring as whole-file ownership: the generator overwrites every section it manages, and no sections pass operator edits through unchanged. Note the two fields the generator does not itself emit and instead inherits from the device's image-provided base config (the DEVICE_METADATA localhost device attributes and the DATABASE schema VERSION); these come from the image, not from operator hand-edits. Bring the code into line with the documented model: - Rebuild owned tables from scratch instead of overwriting only the entries touched in the current run. generate_sonic_config() deep- copies the base config and most helpers assign only the keys they currently generate, so an entry removed from NetBox but still present in config_db.json (e.g. an old VLAN_MEMBER, BGP_GLOBALS VRF, or VXLAN_TUNNEL_MAP) survived regen as stale, active config. Drop the content of every owned table up front and only regenerated entries remain. OWNED_TABLE_KEYS is composed from two named sub-categories: the scaffolded-owned tables (every scaffold key except the inherited DEVICE_METADATA and VERSIONS, created up front via setdefault) and the on-demand owned tables (ROUTE_REDISTRIBUTE, the SNMP_* tables and SYSLOG_SERVER, which helpers assign only when NetBox carries their data). - BGP_GLOBALS['default'] was written with key-level updates that merged into any pre-existing entry, so operator fields survived regen. Replace the entry wholesale when a primary IP is present, like every other generated VRF. - STATIC_ROUTE merged the management default route into the dict loaded from config_db.json, so pre-existing routes (e.g. an operator's custom blackhole or VRF route) survived regen. Clearing the owned tables now drops them before the management route is written. Add tests pinning the model. Illustrative helper tests (test_config_generator_ownership.py) show that _add_vrf_configuration and _add_vlan_configuration replace BGP_GLOBALS[vrf], VLAN entries and ROUTE_REDISTRIBUTE keys wholesale. Orchestrator tests (test_config_generator_orchestrator.py) assert that pre-existing BGP_GLOBALS['default'] fields, STATIC_ROUTE entries, and stale owned-table entries are dropped on regen while DEVICE_METADATA and VERSIONS survive. The ownership tests also pin the table-classification taxonomy: that the scaffold set partitions into scaffolded-owned and inherited tables, that owned and inherited tables are disjoint, that OWNED_TABLE_KEYS has no duplicates, and that the scaffolded-owned and on-demand owned sets do not overlap. Most of the taxonomy holds by construction (OWNED_TABLE_KEYS is derived), so these checks exist to fail when the hand-written INHERITED_TABLE_KEYS or ON_DEMAND_OWNED_TABLE_KEYS literals are edited in a way that would silently break the model. AI-assisted: Claude Code Signed-off-by: Roger Luethi <luethi@osism.tech>
ideaship
added a commit
that referenced
this pull request
Jun 2, 2026
The SONiC config generator owns the config_db.json tables it manages: it generates them from NetBox data and hardcoded SONiC policy, and operators must not make manual adjustments to them. This ownership model was implicit and undocumented, so each PR touching the generator relitigated which sections it owns (surfaced in review of #2279 and #2290). Document the model in the generate_sonic_config() docstring: the generator owns the tables listed in OWNED_TABLE_KEYS and rebuilds them from scratch on every regen. Tables that are neither owned nor inherited are not emitted by the generator and pass through unchanged from the device's image-provided base config_db.json; they are not policed, so they are not a supported place for operator customizations either. Note the two fields the generator does not itself emit and instead inherits from the base config (the DEVICE_METADATA localhost device attributes and the DATABASE schema VERSION); these come from the image, not from operator hand-edits. Bring the code into line with the documented model: - Rebuild owned tables from scratch instead of overwriting only the entries touched in the current run. generate_sonic_config() deep- copies the base config and most helpers assign only the keys they currently generate, so an entry removed from NetBox but still present in config_db.json (e.g. an old VLAN_MEMBER, BGP_GLOBALS VRF, or VXLAN_TUNNEL_MAP) survived regen as stale, active config. Drop the content of every owned table up front and only regenerated entries remain. OWNED_TABLE_KEYS is composed from two named sub-categories: the scaffolded-owned tables (every scaffold key except the inherited DEVICE_METADATA and VERSIONS, created up front via setdefault) and the on-demand owned tables (ROUTE_REDISTRIBUTE, the SNMP_* tables and SYSLOG_SERVER, which helpers assign directly; most only when NetBox carries their data, except SNMP_SERVER, which is always emitted with hardcoded defaults). - BGP_GLOBALS['default'] was written with key-level updates that merged into any pre-existing entry, so operator fields survived regen. Replace the entry wholesale when a primary IP is present, like every other generated VRF. - STATIC_ROUTE merged the management default route into the dict loaded from config_db.json, so pre-existing routes (e.g. an operator's custom blackhole or VRF route) survived regen. Clearing the owned tables now drops them before the management route is written. Add tests pinning the model. Illustrative helper tests (test_config_generator_ownership.py) show that _add_vrf_configuration and _add_vlan_configuration replace BGP_GLOBALS[vrf], VLAN entries and ROUTE_REDISTRIBUTE keys wholesale. Orchestrator tests (test_config_generator_orchestrator.py) assert that pre-existing BGP_GLOBALS['default'] fields, STATIC_ROUTE entries, and stale owned-table entries are dropped on regen while DEVICE_METADATA and VERSIONS survive: a sampled case keeps the assertions readable, and an exhaustive sweep seeds a sentinel into every OWNED_TABLE_KEYS table and asserts none survive regen, so the guarantee covers the whole owned set as it grows. The ownership tests also pin the table-classification taxonomy: that the scaffold set partitions into scaffolded-owned and inherited tables, that owned and inherited tables are disjoint, that OWNED_TABLE_KEYS has no duplicates, and that the scaffolded-owned and on-demand owned sets do not overlap. Most of the taxonomy holds by construction (OWNED_TABLE_KEYS is derived), so these checks exist to fail when the hand-written INHERITED_TABLE_KEYS or ON_DEMAND_OWNED_TABLE_KEYS literals are edited in a way that would silently break the model. AI-assisted: Claude Code Signed-off-by: Roger Luethi <luethi@osism.tech>
berendt
pushed a commit
that referenced
this pull request
Jun 2, 2026
The SONiC config generator owns the config_db.json tables it manages: it generates them from NetBox data and hardcoded SONiC policy, and operators must not make manual adjustments to them. This ownership model was implicit and undocumented, so each PR touching the generator relitigated which sections it owns (surfaced in review of #2279 and #2290). Document the model in the generate_sonic_config() docstring: the generator owns the tables listed in OWNED_TABLE_KEYS and rebuilds them from scratch on every regen. Tables that are neither owned nor inherited are not emitted by the generator and pass through unchanged from the device's image-provided base config_db.json; they are not policed, so they are not a supported place for operator customizations either. Note the two fields the generator does not itself emit and instead inherits from the base config (the DEVICE_METADATA localhost device attributes and the DATABASE schema VERSION); these come from the image, not from operator hand-edits. Bring the code into line with the documented model: - Rebuild owned tables from scratch instead of overwriting only the entries touched in the current run. generate_sonic_config() deep- copies the base config and most helpers assign only the keys they currently generate, so an entry removed from NetBox but still present in config_db.json (e.g. an old VLAN_MEMBER, BGP_GLOBALS VRF, or VXLAN_TUNNEL_MAP) survived regen as stale, active config. Drop the content of every owned table up front and only regenerated entries remain. OWNED_TABLE_KEYS is composed from two named sub-categories: the scaffolded-owned tables (every scaffold key except the inherited DEVICE_METADATA and VERSIONS, created up front via setdefault) and the on-demand owned tables (ROUTE_REDISTRIBUTE, the SNMP_* tables and SYSLOG_SERVER, which helpers assign directly; most only when NetBox carries their data, except SNMP_SERVER, which is always emitted with hardcoded defaults). - BGP_GLOBALS['default'] was written with key-level updates that merged into any pre-existing entry, so operator fields survived regen. Replace the entry wholesale when a primary IP is present, like every other generated VRF. - STATIC_ROUTE merged the management default route into the dict loaded from config_db.json, so pre-existing routes (e.g. an operator's custom blackhole or VRF route) survived regen. Clearing the owned tables now drops them before the management route is written. Add tests pinning the model. Illustrative helper tests (test_config_generator_ownership.py) show that _add_vrf_configuration and _add_vlan_configuration replace BGP_GLOBALS[vrf], VLAN entries and ROUTE_REDISTRIBUTE keys wholesale. Orchestrator tests (test_config_generator_orchestrator.py) assert that pre-existing BGP_GLOBALS['default'] fields, STATIC_ROUTE entries, and stale owned-table entries are dropped on regen while DEVICE_METADATA and VERSIONS survive: a sampled case keeps the assertions readable, and an exhaustive sweep seeds a sentinel into every OWNED_TABLE_KEYS table and asserts none survive regen, so the guarantee covers the whole owned set as it grows. The ownership tests also pin the table-classification taxonomy: that the scaffold set partitions into scaffolded-owned and inherited tables, that owned and inherited tables are disjoint, that OWNED_TABLE_KEYS has no duplicates, and that the scaffolded-owned and on-demand owned sets do not overlap. Most of the taxonomy holds by construction (OWNED_TABLE_KEYS is derived), so these checks exist to fail when the hand-written INHERITED_TABLE_KEYS or ON_DEMAND_OWNED_TABLE_KEYS literals are edited in a way that would silently break the model. AI-assisted: Claude Code Signed-off-by: Roger Luethi <luethi@osism.tech>
ideaship
approved these changes
Jun 2, 2026
Contributor
ideaship
left a comment
ideaship
left a comment
There was a problem hiding this comment.
Revisited after #2297 was merged. I do not see any remaining review findings from the ownership-model decision.
The earlier ROUTE_REDISTRIBUTE fixture concern is addressed in the current diff, and the new helper coverage is consistent with the now-explicit generated-table ownership model. The small generator change is narrowly scoped to optional interface_ips/transfer_ips handling for connected IPv4 neighbors.
One operational caveat: the currently visible checks for this PR ran on 2026-05-19, before #2297 landed, so please re-run CI / Zuul against the current base before merging.
Cover the BGP, VLAN, Loopback and VRF helpers in osism/tasks/conductor/sonic/config_generator.py: - _add_bgp_configurations: BGP_NEIGHBOR_AF and BGP_NEIGHBOR for connected interfaces and port channels, plus VLAN-SVI BGP (untagged-member, transfer-role, switch-to-switch / l2vpn_evpn, non-default VRF and dedup branches) - _get_connected_device_for_interface delegation - _determine_peer_type AS comparison and error handling - _add_vlan_configuration members / VLAN_MEMBER / SVI - _add_loopback_configuration including Loopback0 BGP_GLOBALS_AF_NETWORK - _get_vrf_info naming conventions and error paths - _add_vrf_configuration VNI/table_id/VXLAN/interface assignment Closes #2223 AI-assisted: Claude Code Signed-off-by: Christian Berendt <berendt@osism.tech>
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
3 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.
Closes #2223.
Adds
tests/unit/tasks/conductor/sonic/test_config_generator_bgp_vlan_vrf.pycovering the BGP, VLAN, Loopback and VRF helpers inosism/tasks/conductor/sonic/config_generator.py.Coverage
_add_bgp_configurations—BGP_NEIGHBOR_AF/BGP_NEIGHBORfor connected interfaces and port channels, plus VLAN-SVI BGP: untagged-member exclusion, direct vs. transfer-role IPv4, switch-to-switch /l2vpn_evpntag handling, non-default VRF, peer-IP local-addr resolution and peer-IP dedup_get_connected_device_for_interface— delegation_determine_peer_type— AS-mapping vs. computed ASN, missingprimary_ip4, and exception handling_add_vlan_configuration— members /VLAN_MEMBER/ SVI, unmapped-member warning_add_loopback_configuration—Loopback0BGP_GLOBALS_AF_NETWORK(v4/v6), invalid-IP path_get_vrf_info— both naming conventions, per-interface and top-level error paths_add_vrf_configuration— VNI/table_id/neither,BGP_GLOBALSdeep copy, VXLAN sections, interface/port-channel VRF assignmentNotes
_add_vlan_configurationdoes not actually sortmembersby SONiC name (the issue text says it does); tests assert the real behaviour via an order-independent comparison.loguru_logsfixture.Checks
flake8,python-blackgreen locallymypyruns as a separate Zuul job; the file follows the annotation-freeSimpleNamespacestyle of the existing, CI-green SONiC test filespytestleft to thepython-osism-unit-testsZuul job🤖 Generated with Claude Code