Enhancing Fabric Type Support for Switches Module by AKDRG · Pull Request #405 · CiscoDevNet/ansible-nd

AKDRG · 2026-07-16T09:49:28Z

Proposed Changes

This PR improves nd_manage_switches support for fabric-specific switch onboarding by adding fabric capability validation, exposing supported switch platform types, and improving lifecycle output visibility for config-save and deploy operations.

Changes

Added fabric capability validation before switch discovery/add workflows.
Enforced fabric-specific support for:

switch role
preserve_config
platform_type

Exposed platform_type in the playbook argspec with supported choices:

nx-os
ios-xe
ios-xr
other

Registered finalize operations in module output:

config_save
deploy_switches
deploy_config

Preserved full controller response metadata for finalize API calls where available.
Added/updated unit tests for fabric validation, platform input handling, and finalize output visibility.

Test Notes

Validated against live controller
pytest tests/unit/module_utils/test_nd_switch_resources.py -q
44 passed

Cisco Nexus Dashboard Version

4.2(1)

Related ND API Resource Category

Checklist

Latest commit is rebased from develop with merge conflicts resolved
New or updates to documentation has been made accordingly
Assigned the proper reviewers

allenrobel · 2026-07-16T18:56:50Z

@AKDRG — a heads-up and a question, not a request to change anything here. This PR is doing the right thing; the collision is on my side.

Situation. In #404 I added a PlatformTypeEnum to plugins/module_utils/enums.py for FabricContext.get_platform_type(), which reads additionalData.platformType off GET /fabrics/{fabric}/switches. I did that without noticing your PlatformType in models/manage_switches/enums.py already covers the same ground — same values, except yours also has SONIC, which mine is missing (a real gap: my lookup would silently return None for a SONiC switch). Two enums one token apart in the name is a trap for the next reader, so I'd rather converge than ship the duplicate.

Proposal. Promote PlatformType from models/manage_switches/enums.py up to module_utils/enums.py, and have FabricContext use it. Per CLAUDE.md, module_utils/enums.py is for "Enums commonly used by most module utilities" — with both manage_switches and fabric_context needing it, that's what it's become. The reverse (a top-level util importing from models/manage_switches/) would be a layering inversion.

This shouldn't cost you anything. Done as a move + re-export — leaving PlatformType re-exported from models/manage_switches/enums.py (via __all__, to keep pylint quiet) — every existing import site keeps working untouched, nothing in this PR changes, and you don't need to rebase. module_utils/enums.py imports only from enum import Enum, so there's no cycle, and the re-export lives in a named module rather than __init__.py, so it's clear of the empty-init sanity rule. Two of your changed files (nd_switch_resources.py, config_models.py) are PlatformType consumers, which is exactly why I'd rather not touch import sites while you're in flight.

The question I actually want your read on. Your enums look deliberately endpoint-scoped — PlatformType documented as AddSwitches (POST switches), ShallowDiscoveryPlatformType split out because shallowDiscovery excludes apic. My use is a third context: the GET switches response. Is that response set known to match the AddSwitches request set, or would you rather it stay a separate enum on principle? If they can legitimately diverge, sharing one is the wrong call and I'll keep a distinct read-side enum — properly named and documented, with SONIC added. You know this API surface better than I do.

One detail either way: normalize() defaults None -> NX_OS, which suits the write path but not mine, where "switch reports no platformType" has to stay None. So I'd use the bare enum rather than normalize() regardless.

Happy to do the move in #404 if you're good with it, or leave it to you if you'd rather own that file.

@AKDRG

get_platform_type() resolves via PlatformTypeEnum(raw) inside a try/except ValueError, falling through to None for any value the enum does not know. With SONIC absent, a SONiC switch silently reported "no platform type" rather than its actual platform -- the exact failure the enum exists to prevent. Found while checking PlatformTypeEnum against develop's pre-existing PlatformType (plugins/module_utils/models/manage_switches/enums.py), which has carried SONIC all along. Whether the two enums converge is an open question being discussed with @AKDRG on #405; this gap is a defect either way, so fix it now rather than leave it pending that outcome. If PlatformTypeEnum is later dropped in favor of a promoted PlatformType, this member goes with it. Test: extends 00230 with a fourth switch reporting platformType "sonic", asserting it resolves to PlatformTypeEnum.SONIC. Verified to fail against the unfixed enum (AttributeError: type object 'PlatformTypeEnum' has no attribute 'SONIC'). module_utils suite green: 3036 passed. black/isort/pylint/mypy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aJ3Y2TJEAqJZBeUKdUnGa

@AKDRG

get_platform_type() resolves via PlatformTypeEnum(raw) inside a try/except ValueError, falling through to None for any value the enum does not know. With SONIC absent, a SONiC switch silently reported "no platform type" rather than its actual platform -- the exact failure the enum exists to prevent. Found while checking PlatformTypeEnum against develop's pre-existing PlatformType (plugins/module_utils/models/manage_switches/enums.py), which has carried SONIC all along. Whether the two enums converge is an open question being discussed with @AKDRG on #405; this gap is a defect either way, so fix it now rather than leave it pending that outcome. If PlatformTypeEnum is later dropped in favor of a promoted PlatformType, this member goes with it. Test: extends 00230 with a fourth switch reporting platformType "sonic", asserting it resolves to PlatformTypeEnum.SONIC. Verified to fail against the unfixed enum (AttributeError: type object 'PlatformTypeEnum' has no attribute 'SONIC'). module_utils suite green: 3036 passed. black/isort/pylint/mypy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aJ3Y2TJEAqJZBeUKdUnGa

allenrobel · 2026-07-20T18:26:20Z

@AKDRG thanks for moving PlatformType to plugins/module_utils/enums.py 👍

I'll wait for #405 to merge to leverage PlatformType at its new home.

allenrobel

Code review

Four findings, each as an inline comment: endpoint-import coupling in shared utils.py, role: None rejected by the new fabric-capability validation, a now-dead all_preserve_config flag, and an undocumented ValueError in normalize_platform_type.

🤖 Generated with Claude Code

@AKDRG

get_platform_type() resolves via PlatformTypeEnum(raw) inside a try/except ValueError, falling through to None for any value the enum does not know. With SONIC absent, a SONiC switch silently reported "no platform type" rather than its actual platform -- the exact failure the enum exists to prevent. Found while checking PlatformTypeEnum against develop's pre-existing PlatformType (plugins/module_utils/models/manage_switches/enums.py), which has carried SONIC all along. Whether the two enums converge is an open question being discussed with @AKDRG on #405; this gap is a defect either way, so fix it now rather than leave it pending that outcome. If PlatformTypeEnum is later dropped in favor of a promoted PlatformType, this member goes with it. Test: extends 00230 with a fourth switch reporting platformType "sonic", asserting it resolves to PlatformTypeEnum.SONIC. Verified to fail against the unfixed enum (AttributeError: type object 'PlatformTypeEnum' has no attribute 'SONIC'). module_utils suite green: 3036 passed. black/isort/pylint/mypy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aJ3Y2TJEAqJZBeUKdUnGa

allenrobel

LGTM after comments were addressed.

@AKDRG

get_platform_type() resolves via PlatformTypeEnum(raw) inside a try/except ValueError, falling through to None for any value the enum does not know. With SONIC absent, a SONiC switch silently reported "no platform type" rather than its actual platform -- the exact failure the enum exists to prevent. Found while checking PlatformTypeEnum against develop's pre-existing PlatformType (plugins/module_utils/models/manage_switches/enums.py), which has carried SONIC all along. Whether the two enums converge is an open question being discussed with @AKDRG on #405; this gap is a defect either way, so fix it now rather than leave it pending that outcome. If PlatformTypeEnum is later dropped in favor of a promoted PlatformType, this member goes with it. Test: extends 00230 with a fourth switch reporting platformType "sonic", asserting it resolves to PlatformTypeEnum.SONIC. Verified to fail against the unfixed enum (AttributeError: type object 'PlatformTypeEnum' has no attribute 'SONIC'). module_utils suite green: 3036 passed. black/isort/pylint/mypy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aJ3Y2TJEAqJZBeUKdUnGa

@AKDRG

get_platform_type() resolves via PlatformTypeEnum(raw) inside a try/except ValueError, falling through to None for any value the enum does not know. With SONIC absent, a SONiC switch silently reported "no platform type" rather than its actual platform -- the exact failure the enum exists to prevent. Found while checking PlatformTypeEnum against develop's pre-existing PlatformType (plugins/module_utils/models/manage_switches/enums.py), which has carried SONIC all along. Whether the two enums converge is an open question being discussed with @AKDRG on #405; this gap is a defect either way, so fix it now rather than leave it pending that outcome. If PlatformTypeEnum is later dropped in favor of a promoted PlatformType, this member goes with it. Test: extends 00230 with a fourth switch reporting platformType "sonic", asserting it resolves to PlatformTypeEnum.SONIC. Verified to fail against the unfixed enum (AttributeError: type object 'PlatformTypeEnum' has no attribute 'SONIC'). module_utils suite green: 3036 passed. black/isort/pylint/mypy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aJ3Y2TJEAqJZBeUKdUnGa

@AKDRG

get_platform_type() resolves via PlatformTypeEnum(raw) inside a try/except ValueError, falling through to None for any value the enum does not know. With SONIC absent, a SONiC switch silently reported "no platform type" rather than its actual platform -- the exact failure the enum exists to prevent. Found while checking PlatformTypeEnum against develop's pre-existing PlatformType (plugins/module_utils/models/manage_switches/enums.py), which has carried SONIC all along. Whether the two enums converge is an open question being discussed with @AKDRG on #405; this gap is a defect either way, so fix it now rather than leave it pending that outcome. If PlatformTypeEnum is later dropped in favor of a promoted PlatformType, this member goes with it. Test: extends 00230 with a fourth switch reporting platformType "sonic", asserting it resolves to PlatformTypeEnum.SONIC. Verified to fail against the unfixed enum (AttributeError: type object 'PlatformTypeEnum' has no attribute 'SONIC'). module_utils suite green: 3036 passed. black/isort/pylint/mypy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aJ3Y2TJEAqJZBeUKdUnGa

@AKDRG

get_platform_type() resolves via PlatformTypeEnum(raw) inside a try/except ValueError, falling through to None for any value the enum does not know. With SONIC absent, a SONiC switch silently reported "no platform type" rather than its actual platform -- the exact failure the enum exists to prevent. Found while checking PlatformTypeEnum against develop's pre-existing PlatformType (plugins/module_utils/models/manage_switches/enums.py), which has carried SONIC all along. Whether the two enums converge is an open question being discussed with @AKDRG on #405; this gap is a defect either way, so fix it now rather than leave it pending that outcome. If PlatformTypeEnum is later dropped in favor of a promoted PlatformType, this member goes with it. Test: extends 00230 with a fourth switch reporting platformType "sonic", asserting it resolves to PlatformTypeEnum.SONIC. Verified to fail against the unfixed enum (AttributeError: type object 'PlatformTypeEnum' has no attribute 'SONIC'). module_utils suite green: 3036 passed. black/isort/pylint/mypy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aJ3Y2TJEAqJZBeUKdUnGa

allenrobel

Code review

Incremental review of the three commits since my last review (Fix Preserve Config, Platform Type Validation + Support Docs, Remove support for IPFM/Tier2, Refine switch preserve config capabilities). One finding, posted inline — a follow-up to the earlier (resolved) IPFM thread.

🤖 Generated with Claude Code

@AKDRG

get_platform_type() resolves via PlatformTypeEnum(raw) inside a try/except ValueError, falling through to None for any value the enum does not know. With SONIC absent, a SONiC switch silently reported "no platform type" rather than its actual platform -- the exact failure the enum exists to prevent. Found while checking PlatformTypeEnum against develop's pre-existing PlatformType (plugins/module_utils/models/manage_switches/enums.py), which has carried SONIC all along. Whether the two enums converge is an open question being discussed with @AKDRG on #405; this gap is a defect either way, so fix it now rather than leave it pending that outcome. If PlatformTypeEnum is later dropped in favor of a promoted PlatformType, this member goes with it. Test: extends 00230 with a fourth switch reporting platformType "sonic", asserting it resolves to PlatformTypeEnum.SONIC. Verified to fail against the unfixed enum (AttributeError: type object 'PlatformTypeEnum' has no attribute 'SONIC'). module_utils suite green: 3036 passed. black/isort/pylint/mypy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aJ3Y2TJEAqJZBeUKdUnGa

@AKDRG

get_platform_type() resolves via PlatformTypeEnum(raw) inside a try/except ValueError, falling through to None for any value the enum does not know. With SONIC absent, a SONiC switch silently reported "no platform type" rather than its actual platform -- the exact failure the enum exists to prevent. Found while checking PlatformTypeEnum against develop's pre-existing PlatformType (plugins/module_utils/models/manage_switches/enums.py), which has carried SONIC all along. Whether the two enums converge is an open question being discussed with @AKDRG on #405; this gap is a defect either way, so fix it now rather than leave it pending that outcome. If PlatformTypeEnum is later dropped in favor of a promoted PlatformType, this member goes with it. Test: extends 00230 with a fourth switch reporting platformType "sonic", asserting it resolves to PlatformTypeEnum.SONIC. Verified to fail against the unfixed enum (AttributeError: type object 'PlatformTypeEnum' has no attribute 'SONIC'). module_utils suite green: 3036 passed. black/isort/pylint/mypy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aJ3Y2TJEAqJZBeUKdUnGa

@AKDRG

get_platform_type() resolves via PlatformTypeEnum(raw) inside a try/except ValueError, falling through to None for any value the enum does not know. With SONIC absent, a SONiC switch silently reported "no platform type" rather than its actual platform -- the exact failure the enum exists to prevent. Found while checking PlatformTypeEnum against develop's pre-existing PlatformType (plugins/module_utils/models/manage_switches/enums.py), which has carried SONIC all along. Whether the two enums converge is an open question being discussed with @AKDRG on #405; this gap is a defect either way, so fix it now rather than leave it pending that outcome. If PlatformTypeEnum is later dropped in favor of a promoted PlatformType, this member goes with it. Test: extends 00230 with a fourth switch reporting platformType "sonic", asserting it resolves to PlatformTypeEnum.SONIC. Verified to fail against the unfixed enum (AttributeError: type object 'PlatformTypeEnum' has no attribute 'SONIC'). module_utils suite green: 3036 passed. black/isort/pylint/mypy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aJ3Y2TJEAqJZBeUKdUnGa

@AKDRG

get_platform_type() resolves via PlatformTypeEnum(raw) inside a try/except ValueError, falling through to None for any value the enum does not know. With SONIC absent, a SONiC switch silently reported "no platform type" rather than its actual platform -- the exact failure the enum exists to prevent. Found while checking PlatformTypeEnum against develop's pre-existing PlatformType (plugins/module_utils/models/manage_switches/enums.py), which has carried SONIC all along. Whether the two enums converge is an open question being discussed with @AKDRG on #405; this gap is a defect either way, so fix it now rather than leave it pending that outcome. If PlatformTypeEnum is later dropped in favor of a promoted PlatformType, this member goes with it. Test: extends 00230 with a fourth switch reporting platformType "sonic", asserting it resolves to PlatformTypeEnum.SONIC. Verified to fail against the unfixed enum (AttributeError: type object 'PlatformTypeEnum' has no attribute 'SONIC'). module_utils suite green: 3036 passed. black/isort/pylint/mypy clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aJ3Y2TJEAqJZBeUKdUnGa

allenrobel

Re-verified the post-08-13 delta (d0e213cc, 041a2b62): the fabric exposure gate is now enforced before every mutating state including deleted and empty overridden, DOCUMENTATION matches the supported set, and the switch-resources unit tests pass locally (74 passed). LGTM.

mikewiebe · 2026-08-25T19:11:38Z

Merging with 2 required approvals

…type The enums.py hunk this commit originally carried (adding SONIC to PlatformTypeEnum) was dropped on rebase: develop's PlatformType (promoted by #405) already includes SONIC. The fixture and assertion guarding the silent-None fall-through remain.

#405 promoted PlatformType (nx-os/other/ios-xe/ios-xr/sonic/apic) to module_utils/enums.py, which is the enum FabricContext.get_platform_type() was always meant to share. Point the read path at it and remove the duplicate read-side PlatformTypeEnum this PR had introduced. normalize() is deliberately not used here: its None -> NX_OS default would mask a switch that reports no platformType, which must stay None.

…type The enums.py hunk this commit originally carried (adding SONIC to PlatformTypeEnum) was dropped on rebase: develop's PlatformType (promoted by #405) already includes SONIC. The fixture and assertion guarding the silent-None fall-through remain.

#405 promoted PlatformType (nx-os/other/ios-xe/ios-xr/sonic/apic) to module_utils/enums.py, which is the enum FabricContext.get_platform_type() was always meant to share. Point the read path at it and remove the duplicate read-side PlatformTypeEnum this PR had introduced. normalize() is deliberately not used here: its None -> NX_OS default would mask a switch that reports no platformType, which must stay None.

…type The enums.py hunk this commit originally carried (adding SONIC to PlatformTypeEnum) was dropped on rebase: develop's PlatformType (promoted by #405) already includes SONIC. The fixture and assertion guarding the silent-None fall-through remain.

#405 promoted PlatformType (nx-os/other/ios-xe/ios-xr/sonic/apic) to module_utils/enums.py, which is the enum FabricContext.get_platform_type() was always meant to share. Point the read path at it and remove the duplicate read-side PlatformTypeEnum this PR had introduced. normalize() is deliberately not used here: its None -> NX_OS default would mask a switch that reports no platformType, which must stay None.

Enhancing Fabric Type Support for Switches Module

b17e567

AKDRG self-assigned this Jul 16, 2026

AKDRG requested review from akinross, allenrobel, anvitha-jain, gmicol, lhercot, mikewiebe, mtarking, sajagana, samiib and shrsr as code owners July 16, 2026 09:49

akinross requested changes Jul 16, 2026

View reviewed changes

Comment thread plugins/module_utils/manage_switches/fabric_switch_capabilities.py

allenrobel mentioned this pull request Jul 16, 2026

FabricContext: expose platform_type, retain switch records, fail closed (#399, #400) #404

Open

10 tasks

AKDRG added 2 commits July 17, 2026 14:34

Handle Reload Support for IOS-XE, Move Platform Enum to Global Enums

eb65cb8

Restructuring Utils

d4963d3

allenrobel reviewed Jul 20, 2026

View reviewed changes

Comment thread plugins/module_utils/utils.py Outdated

Comment thread plugins/module_utils/manage_switches/fabric_capabilities.py Outdated

Comment thread plugins/module_utils/manage_switches/nd_switch_resources.py

Comment thread plugins/module_utils/models/manage_switches/config_models.py

AKDRG added 2 commits July 21, 2026 14:00

Fix Docstrings, Fabric Dependency, Cleanup Unused Functions, Code

e8b7c98

Fix Sanity

1d63a4f

AKDRG mentioned this pull request Jul 21, 2026

Vrf_lite module for Ansible ND 4.x #281

Open

Fix Support Matrix for Platform, Fabric

7fbfa7c

AKDRG added the ready for review Submitter is requesting a PR review label Jul 22, 2026

allenrobel previously approved these changes Jul 23, 2026

View reviewed changes

AKDRG requested a review from akinross July 23, 2026 14:47

sivakasi-cisco added the nac-0.0.1 NaC ND release 0.0.1 label Jul 23, 2026

mikewiebe reviewed Jul 28, 2026

View reviewed changes

Comment thread plugins/module_utils/manage_switches/nd_switch_resources.py

mtarking requested changes Jul 28, 2026

View reviewed changes

mikewiebe mentioned this pull request Jul 28, 2026

Module Support for config_actions + resource level deploy where applicable #368

Open

AKDRG added 2 commits July 29, 2026 14:05

Fix Preserve Config, Platform Type Validation + Support Docs

024345f

Remove support for IPFM/Tier2

b2a509b

AKDRG dismissed stale reviews from akinross and allenrobel via b2a509b July 30, 2026 22:24

AKDRG mentioned this pull request Aug 6, 2026

Enhance nd_manage_switches fabric type support and switch onboarding validation #488

Closed

Refine switch preserve config capabilities

6ebfab3

allenrobel reviewed Aug 13, 2026

View reviewed changes

Comment thread plugins/module_utils/manage_switches/fabric_switch_capabilities.py

Gate switch onboarding fabric support

d0e213c

Fix switch fabric capability edge cases

041a2b6

mikewiebe approved these changes Aug 24, 2026

View reviewed changes

allenrobel approved these changes Aug 25, 2026

View reviewed changes

mikewiebe merged commit 4f4239b into CiscoDevNet:develop Aug 25, 2026
63 checks passed

Uh oh!

Conversation

AKDRG commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposed Changes

Test Notes

Cisco Nexus Dashboard Version

Related ND API Resource Category

Checklist

Uh oh!

Uh oh!

allenrobel commented Jul 16, 2026

Uh oh!

allenrobel commented Jul 20, 2026

Uh oh!

allenrobel left a comment

Choose a reason for hiding this comment

Code review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

allenrobel left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

allenrobel left a comment

Choose a reason for hiding this comment

Code review

Uh oh!

Uh oh!

allenrobel left a comment

Choose a reason for hiding this comment

Uh oh!

mikewiebe commented Aug 25, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

AKDRG commented Jul 16, 2026 •

edited

Loading