Skip to content

Treat HTTP 207 no-command switch deploys as successful no-ops - #573

Draft
nikhilsrikrishna wants to merge 3 commits into
CiscoDevNet:developfrom
nikhilsrikrishna:fix/nd-switch-deploy-no-commands-207
Draft

nikhilsrikrishna wants to merge 3 commits into
CiscoDevNet:developfrom
nikhilsrikrishna:fix/nd-switch-deploy-no-commands-207

Conversation

@nikhilsrikrishna

@nikhilsrikrishna nikhilsrikrishna commented Sep 17, 2026

Copy link
Copy Markdown
Collaborator

Related Issue(s)

N/A — fixes false failures for valid no-op switch deployments.

This change is also required by #495 for Interface Groups switch-level deployment on vPC-paired switches.

Why This Change Is Needed

POST /api/v1/manage/fabrics/{fabric}/switchActions/deploy can return HTTP 207 when the deployment request was handled successfully but one of the included switches has no pending configuration:

{
  "switchId": "SN2",
  "status": "notExecuted",
  "message": "No Commands to execute"
}

This is a valid no-op in two known workflows:

Policy pending-delete cleanup

For state: deleted with deploy: true, a requested policy may no longer appear in the active-policy cache because markDeleted policies and generated child policies are intentionally filtered out.

The module therefore supports a blind pending-delete cleanup path: when the switch is known but the active policy is absent, it calls switchActions/deploy to apply any previously staged deletion.

If that deletion has already converged, or the switch otherwise has no remaining pending commands, NDFC returns notExecuted / No Commands to execute. The deployment request is valid and the switch is already in the desired state, so this response must not fail the Ansible task.

The same response can also occur during a repeated normal delete/deploy after the first operation has already removed the pending configuration.

Interface Groups vPC peer deployment

Interface Groups supports switch-level deployment. When the affected switch belongs to a vPC pair, NDFC can internally include the peer switch in the deployment operation.

The requested switch may deploy successfully while its already-synchronized peer is returned as:

  • status: notExecuted
  • message: No Commands to execute

The peer result is a successful no-op and should not cause the complete Interface Groups deployment to fail.

Previously, NdV1Strategy treated every HTTP 207 item whose status was not exactly success as fatal. This caused valid switch deployments to be reported as failures.

Proposed Changes

  • Accept the exact notExecuted / No Commands to execute result as a successful no-op only when:
    • the endpoint is switchActions/deploy;
    • the response item is under DATA.switchIds[];
    • the item contains a non-empty switchId; and
    • both the status and message match the known no-op response.
  • Continue treating the same response as an error on every other endpoint and response envelope.
  • Continue failing mixed HTTP 207 responses when any switch reports a genuine failure.
  • Add response-handler coverage for exact matches, near matches, mixed success/no-op responses, and mixed no-op/failure responses.
  • Exercise the policy-group switch deployment path with an actual HTTP 207 no-command response.

This is implemented in the shared response strategy because Policies, Policy Groups, and Interface Groups all use the same switchActions/deploy endpoint.

Test Notes

  • Targeted response-handler and policy-group unit tests: 196 passed.
  • Full unit suite: 4729 passed.
  • ansible-test sanity --python 3.11: passed.
  • Black validation using the repository’s 159-character limit: passed.
  • Collection build: passed (cisco-nd-1.5.0.tar.gz).
  • ND 4.3 policy regression:
    • Created and deployed a unique policy.
    • Ran the initial delete/deploy and an immediate repeated delete/deploy.
    • Both operations completed without module failure.
    • The policy GET subsequently returned 404.
    • Switch preview ended inSync with zero pending commands.
  • ND 4.2 nd_manage_policy_group integration on VXLAN_Fabric:
    • Five files passed in the complete run.
    • The deleted setup initially encountered a transient NDFC device-delivery HTTP 207.
    • A clean isolated rerun of deleted passed all 25 tasks.
    • The repeated delete with deploy: true returned changed: false and passed instead of failing on the no-command response.
    • All six committed test files therefore passed on the same lab.
  • Final verification showed zero active policy groups, zero policy-summary rows, zero pending commands, and all three switches inSync.

Cisco Nexus Dashboard Version

4.2 and 4.3

Related ND API Resource Category

  • analyze
  • infa
  • manage
  • onemanage
  • other

Checklist

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

@nikhilsrikrishna
nikhilsrikrishna marked this pull request as ready for review September 18, 2026 11:34
@nikhilsrikrishna
nikhilsrikrishna marked this pull request as draft September 18, 2026 11:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant