Merge pull request #300367 from MicrosoftDocs/main

Sync

Author: prmerger-automator[bot]

articles/operator-nexus/TOC.yml

@@ -50,6 +50,8 @@
           href: concepts-disable-border-gateway-protocol-neighbors.md
         - name: Network Packet Broker
           href: concepts-nexus-network-packet-broker.md
+        - name: Commit Workflow v2
+          href: concepts-commit-workflow-v2.md
         - name: Route Policy
           expanded: false
           items:
@@ -246,6 +248,8 @@
           href: concepts-bmp-log-streaming.md
         - name: How to enable / disable BMP log streaming Azure Operator Nexus
           href: howto-enable-log-streaming.md
+        - name: How to use Commit Workflow v2 in Azure Operator Nexus
+          href: howto-use-commit-workflow-v2.md
     - name: Cluster
       expanded: false
       items:

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

@@ -0,0 +1,118 @@
+---
+title: How to use Commit Workflow v2 in Azure Operator Nexus
+description: Learn the process for using Commit Workflow v2 in Nexus Network Fabric
+author: sushantjrao 
+ms.author: sushrao
+ms.date: 05/26/2025
+ms.topic: how-to
+ms.service: azure-operator-nexus
+ms.custom: template-how-to, devx-track-azurecli
+---
+
+# How to use Commit Workflow v2 in Azure Operator Nexus
+
+The **Commit Workflow v2** ensures that device-impacting changes to a Network Fabric instance are explicitly acknowledged and committed before being applied to the underlying infrastructure. This structured workflow increases reliability and control over configuration changes.
+
+## Prerequisites
+
+* **Runtime version**: `5.0.1` or later is required for Commit Workflow v2.
+
+* Your **Network Fabric must be in `Provisioned` state** and **configuration state must be `Succeeded`**.
+
+* The **fabric and all impacted resources must have admin state set to `Enabled`**.
+
+* You must have **BYOS (Bring Your Own Storage)** configured on the fabric to use the optional validation step.
+
+## Commit Workflow v2 overview
+
+Any `patch` operation on parent resources or `Create`/`Update`/`Delete` (CUD) operation on connected child resources now requires an explicit commit step. Changes are **batched** until you lock, validate (optional), and commit them.
+
+### Step 1: Update resources
+
+Make patch or CUD operations via Azure CLI, Portal, or ARM template.
+Once these changes are made, the fabric's configuration state will change to `Accepted (Pending Commit)`.
+
+#### Example scenarios
+
+* Create a new **Route Policy** and attach it to **Internal Network 1**
+
+* Create another **Internal Network 2**
+
+All these changes are **batched**, but **not applied** to devices yet.
+
+
+### Step 2: Lock Configuration (Mandatory)
+
+Lock the configuration to signal that all intended updates are completed. After this lock, **no further updates** can be made to any fabric-related resources until you unlock.
+
+#### Azure CLI Command
+
+```Azure CLI
+az networkfabric fabric lock-fabric \
+    --action Lock \
+    --lock-type Configuration \
+    --network-fabric-name "example-fabric" \
+    --resource-group "example-rg"
+```
+
+- Successful execution transitions the fabric to a **locked state**.
+
+- Check CLI output for success or failure status.
+
+
+### Step 3: Validate updates (Optional but recommended)
+
+Validate the configuration using the `view-device-configuration` post-action. This step provides insight into the expected configuration outcomes.
+
+> [!Important] 
+> BYOS must be configured on the Network Fabric.
+
+#### Azure CLI Command
+
+```Azure CLI
+
+az networkfabric fabric view-device-configuration \
+    --network-fabric-name "example-fabric"\
+    --resource-group "example-rg"
+```
+
+- **Pre-Device Changes**: Current config for all devices (CE, TOR, Management Switches)
+
+- **Post-Device Changes**: Preview of what will be applied after commit
+
+#### Need to Make More Updates?
+
+Unlock the configuration to make further changes, then repeat the lock/validate/commit steps.
+
+#### Unlock Example
+
+```Azure CLI
+az networkfabric fabric lock-fabric \
+    --action Unlock \
+    --lock-type Configuration \
+    --network-fabric-name "example-fabric" \
+    --resource-group "example-rg"
+```
+
+### Step 4: Commit Configuration (Mandatory)
+
+Commit the configuration to apply the batched changes to all relevant fabric devices.
+
+#### Azure CLI Command
+
+```Azure CLI
+az networkfabric fabric commit-configuration \
+  --resource-group "example-rg" \
+  --resource-name "example-fabric"
+```
+
+- The operation returns a **status**: `Succeeded`, `InProgress`, or `Failed`
+
+- Use CLI polling or Azure Activity Logs to monitor progress
+
+> [!Important]
+> - This workflow applies **only when the fabric is in Provisioned state** and **admin state is Enabled**. <br>
+> - Locking is mandatory before commit; **commit cannot proceed without locking first**. <br>
+> - **Rollback is not supported** – any incorrect configuration must be updated and re-committed. <br>
+> - Updates outside of this workflow (e.g., to tags or disconnected resources) do **not require commit**. <br>
+

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

@@ -276,7 +276,9 @@ Azure NetApp Files requires a delegated subnet, which must be part of the same v
 
 1. Create the delegated subnet for *Microsoft.NetApp/volumes*.
 
-   ![Screenshot that shows selections for adding a delegated subnet.](media/lama/sap-lama-addsubnet-50.png)
+   ![Screenshot that shows selections for adding subnet.](media/lama/sap-lama-addsubnet-50.png)
+   
+   ![Screenshot that shows selections for choosing subnet delegation.](media/lama/sap-lama-addsubnet2-50.png)
 
    ![Screenshot that shows a list of subnets.](media/lama/sap-lama-subnets.png)
 
@@ -322,10 +324,10 @@ Azure NetApp Files requires a delegated subnet, which must be part of the same v
    1. Mount the Azure NetApp Files volumes by using the following commands:
 
       ```bash
-      # sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,vers=3,tcp 9.9.9.132:/an1-home-sidadm /home/an1adm
-      # sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,vers=3,tcp 9.9.9.132:/an1-sapmnt-sid /sapmnt/AN1
-      # sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,vers=3,tcp 9.9.9.132:/an1-usr-sap-sid /usr/sap/AN1
-      # sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,vers=3,tcp 9.9.9.132:/global-usr-sap-trans /usr/sap/trans
+      # sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,vers=3,tcp 10.1.0.133:/an1-home-sidadm /home/an1adm
+      # sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,vers=3,tcp 10.1.0.134:/an1-sapmnt-sid /sapmnt/AN1
+      # sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,vers=3,tcp 10.1.0.134:/an1-usr-sap-sid /usr/sap/AN1
+      # sudo mount -t nfs -o rw,hard,rsize=65536,wsize=65536,vers=3,tcp 10.1.0.134:/global-usr-sap-trans /usr/sap/trans
       ```
 
       You can also look up the mount commands from the portal. The local mount points need to be adjusted.