Vrf_lite module for Ansible ND 4.x

[sivakasi-cisco]

Related Issue(s)

• [ND 4.2+] Add VRF-Lite Module #235

This PR adds a new nd_manage_vrf_lite module for managing VRF Lite attachments on Nexus Dashboard / NDFC 4.x fabrics.

The module supports:

• gathered
• merged
• replaced
• overridden
• deleted

The implementation uses the existing NDStateMachine pattern, but keeps the VRF Lite-specific API details in a dedicated orchestrator and helper files under plugins/module_utils/manage_vrf_lite.

Main things included in this PR:

• New cisco.nd.nd_manage_vrf_lite module
• VRF Lite models for nested playbook input and flat runtime attachment entries
• Query, attach, detach, save, deploy, and verification helpers
• Support for config_actions.save and config_actions.deploy
• Support for check mode previews
• Guardrails for switch lookup, VRF existence, and VRF Lite support validation
• Unit and integration tests for merge, replace, override, delete, gather, deploy, and check mode flows

Note: issubset() list matching changed from greedy to bipartite matching. This affects all callers (including nd.py idempotency checks), strictly in the "fewer false changed" direction.

[allenrobel]

Code review

Found 6 issues, posted as inline comments below so each can be resolved individually.
Highlights: the module is built on the abandoned nd_v2 NDModule transport instead of the Gen-3 orchestrator RestSend path; the switch inventory is fetched twice per run, bypassing FabricContext; and validation issues a per-attachment GET (N+1).

Also, a couple general comments.

1. It would be helpful for reviewers if the PR Description template was completed so that we have a summary of what the PR contains, design decisions, caveats, workarounds required, unit test coverage, etc.
2. The title of the PR implies this is a draft. Since, it's now labeled "Ready for Review" you might want to edit the title to remove "initial draft"

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[sivakasi-cisco]

Hi Sivakami, Adding a note here as per our discussion. Everything else looks good. Pending: Need to use the common fabric details utility for the type from fabric_details_cache once #405 is merged.

Thank you for the comments, Akshay.
I have added a To-Do comment on this.

On the offline comments you had shared, I have addressed the possible items.

1. If force is not being used then we can remove it right? Additionally verify too - - addressed, removed the force option which is unused
2. Yeah, this is where we might have issues. Let's say module is running and getting stuck somewhere in between. We won't know where - Addressed - added logging
3. "That makes me to think if we require any tests to be performed for interface changes from one vrf to other? In that case, a 2 step deploy would be required." this is what i was thinking too. Can you test this one out?
   For the overridden part, there are no 2 deployments in the implemented approach and I'm planning to continue with the same, because of the below resons.
   It first compares the current and desired config, stage the updates/add/remove from ND and saves it. Then deploys the final config and verifies. So, I did not add any delay to it for removal and addition.
   I tried another approach which require 2 different deploy cycles.
   Both approaches work. So, I'm planning to stick with deploy that matches with our other plans of config_save as well which is through a single shot deploy.

[allenrobel]

Re-review after the new commits (my earlier approval was dismissed by the June pushes).

First, credit where due: I verified all 15 previously-raised review threads against the current code, and every one is genuinely addressed — deploy targets now derive from the state-machine operation journal (with real wire-payload tests proving replaced/overridden removals deploy to the removed switches, including check mode), config_actions.type correctly scopes deploy, the check-mode preflight exists, nd_v2 is gone, FabricContext is used with a shared inventory cache, and the bulk validation N+1 is fixed with request-count tests. The unit suite is largely real-assertion (wire payloads, request counts, exact endpoint paths). Nice work.

The inline comments below are new findings from this pass, roughly ordered by severity:

• Two framework-level concerns in nd_state_machine.py / models/base.py: the merged-state allow_superset diff change applies ungated to every Gen-3 module (with a concrete idempotency regression scenario on shipped interface modules), and diff/merge now disagree about list semantics.
• Two model-validation range bugs (dot1q, vlan_id) confirmed against the ND 4.2.1 OpenAPI schema, plus a vrf_name length that matches no schema constraint.
• A failure-detection gap that can report a failed attachment as success.
• Check-mode vs real-run validation divergence.
• Several unmarked ND-API workarounds that need TODO(X.Y.Z) <slug> markers per the repo convention.
• Endpoint-layer duplication/dead code, the ignore-2.15.txt sanity file, integration teardown leaving deployed config on switches, and a typing convention in utils.py.

[sivakasi-cisco]

I had resolved the comments here, but for the vault-note mentions on TODO(4.2.1) markers, could you pls help me with some reference?

[allenrobel]

I had resolved the comments here, but for the vault-note mentions on TODO(4.2.1) markers, could you pls help me with some reference?

Replied via Webex with references.

[allenrobel]

LGTM after comments were addressed.

One minor nit, the TODO(4.2.1) marker should not contain 'slug: '.

Example (correct):

TODO(4.2.1) vrf-lite-vlan-shape-drift

Example (incorrect):

TODO(4.2.1) slug: vrf-lite-vlan-shape-drift

But this is a consistency/style nit. Functionally, 'slug: ' works, but it's more verbose.

[sivakasi-cisco]

slug

Addressed them in the last changes. Confirmed that there is no "slug:" form anywhere in the code.