Release-8.3

Author: sushantjrao

articles/operator-nexus/concepts-commit-workflow-v2.md

@@ -19,13 +19,21 @@ With this update, users can lock configuration states, preview device-level chan
 
 Commit Workflow v2 is built around a structured change management flow. The following core features are available:
 
-- **Explicit configuration locking:** Users must explicitly lock the configuration of a Network Fabric resource after making changes. This process ensures updates are applied in a predictable and controlled manner.
+- **Explicit configuration locking:**
+  Users must explicitly lock the configuration of a Network Fabric resource after making changes. This process ensures updates are applied in a predictable and controlled manner.
 
-- **Full device configuration preview:** Enables visibility into the exact configuration that is applied to each device before the commit. This helps validate intent and catch issues early.
+- **Full device configuration preview:**
+  Enables visibility into the exact configuration that is applied to each device before the commit. This helps validate intent and catch issues early.
 
-- **Commit configuration to devices**
+- **Commit configuration to devices:**
   Once validated, changes can be committed to the devices. This final step applies the locked configuration updates across the fabric.
 
+- **Discard Batch Updates:**
+  Allows rollback of all uncommitted resource changes to their last known state.
+
+- **Enhanced Constraints:**
+  Enforces strict update rules during lock/maintenance/upgrade phases for stability.
+
 ## Prerequisites
 
 Before using Commit Workflow v2, ensure the following environment requirements are met:
@@ -52,27 +60,51 @@ Before using Commit Workflow v2, ensure the following environment requirements a
 
 Commit Workflow v2 introduces new operational expectations and constraints to ensure consistency and safety in configuration management:
 
-- **Availability & Irreversibility**
+### Availability & locking rules 
+
+- Available only on Runtime Version 5.0.1+. Downgrade to v1 is not supported.
+
+- Locking is allowed only when:
+
+  - No commit is in progress.
+
+  - Fabric is not under maintenance or upgrade.
+
+  - Fabric is in an administrative enabled state.
+
+### Unsupported during maintenance or upgrade
+
+`Lock`, `ViewDeviceConfiguration`, and `related post-actions` are not allowed during maintenance or upgrade windows.
+
+### Commit Finality
+
+Once committed, changes **can't be rolled back**. Any further edits require a new lock-validate-commit cycle.
+
+### Discard Batch Behavior
+
+- The `discard-commit-batch` operation:
+
+  - Reverts all ARM resource changes to their last known good state.
 
-Commit Workflow v2 is only available after upgrading to Runtime Version 5.0.1. Once upgraded, reverting to Commit Workflow v1 is n't supported.
+  - Updates admin/config states (e.g., external/internal networks become disabled and rejected).
 
-- **Configuration lock requirements**
+  - Does not delete resources; users must delete them manually if desired.
 
-Locking is only possible when:
+  - Enables further patching to reapply changes.
 
-- There's no ongoing commit operation.
+- When the discard batch action is performed:
 
-- The fabric isn't in maintenance or upgrade mode.
+  - The administrative state of internal/external network resources moves to disabled and their configuration state to rejected; however, the resources are not deleted automatically. A separate delete operation is required for removal.
 
-- The fabric is in an administrative enabled state.
+  - Enabled Network Monitor resources attached to a fabric cannot be attached to another fabric unless first detached and committed.
 
-- **Unsupported during maintenance or upgrade**
+  - For Network Monitor resources in administrative state disabled (in commit queue), discard batch moves the config state to rejected. Users can re-apply updates (PUT/patch) and commit again to enable.
 
-Configuration Lock and View Device Configuration aren't allowed during maintenance or upgrade windows.
+### Resource update restrictions
 
-- **Commit is final**
+**Post-lock**, only a limited set of `Create`/`Update`/`Delete` (CUD) actions are supported (e.g., unattached ACLs, TAP rules).
 
-Once a configuration is committed, it can't be rolled back. Future changes must go through another lock-commit cycle.
+Device-impacting resources (like Network-to-Network Interconnect (NNI), Isolation Domain (ISD), Route Policy, or ACLs attached to parent resources) are blocked during configuration lock.
 
 ### Supported resource actions via Commit workflow v2 (when parent resources are in administrative state – Enabled)
 
@@ -87,7 +119,7 @@ Here's a clear, structured table showing **Supported actions post configuration
 
 ---
 
-### **Supported and unsupported actions Post configuration lock**
+### **Supported and unsupported actions post configuration lock**
 
 | **Actions**                          | **Supported resource actions when fabric is under configuration lock**                                                                                                                                                                                                                                                                                                                                                                                                                                                                   | **Unsupported resource actions when fabric is under configuration lock**                                                                                                                                                                                                                                                                                                                                                                                           |
 | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |

articles/operator-nexus/howto-use-commit-workflow-v2.md

@@ -82,6 +82,22 @@ az networkfabric fabric view-device-configuration \
 
 - **Post-Device Changes**: Preview of what will be applied after commit
 
+### Step 3a: Discard commit batch (Optional)
+
+After validating with ViewDeviceConfiguration, users may discard pending configuration updates if issues are found. This restores the ARM resource state to its last known good configuration and resets the fabric state from Accepted & Locked to Succeeded.
+
+
+```Azure CLI
+az networkfabric fabric discard-commit-batch \
+  --resource-group "example-rg" \
+  --network-fabric-name "example-fabric"
+```
+
+> [!Note]
+> Internal/External network resources move to Admin State: Disabled and Config State: Rejected.<br>
+> Resources are not deleted — user must delete them manually if required.<br>
+> Network Monitor handling includes additional constraints (disabled monitors revert to rejected state).<br>
+
 #### Need to Make More Updates?
 
 Unlock the configuration to make further changes, then repeat the lock/validate/commit steps.