Skip to content

Commit f830a3a

Browse files
sushantjraosushantjrao
committed
Commit workflow v2 Feature
1 parent 801ddc1 commit f830a3a

File tree

3 files changed

+228
-0
lines changed

3 files changed

+228
-0
lines changed

‎articles/operator-nexus/TOC.yml

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -50,6 +50,8 @@
5050
href: concepts-disable-border-gateway-protocol-neighbors.md
5151
- name: Network Packet Broker
5252
href: concepts-nexus-network-packet-broker.md
53+
- name: Commit Workflow v2
54+
href: concepts-commit-workflow-v2
5355
- name: Route Policy
5456
expanded: false
5557
items:
@@ -246,6 +248,8 @@
246248
href: concepts-bmp-log-streaming.md
247249
- name: How to enable / disable BMP log streaming Azure Operator Nexus
248250
href: howto-enable-log-streaming.md
251+
- name: How to use Commit Workflow v2 in Azure Operator Nexus
252+
href: howto-use-commit-workflow-v2.md
249253
- name: Cluster
250254
expanded: false
251255
items:

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

Lines changed: 106 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,106 @@
1+
---
2+
title: Azure Operator Nexus – Network Fabric - Commit Workflow v2
3+
description: Learn about Commit Workflow v2 process in Azure Operator Nexus – Network Fabric
4+
author: sushantjrao
5+
ms.author: sushrao
6+
ms.service: azure-operator-nexus
7+
ms.topic: conceptual
8+
ms.date: 05/16/2025
9+
ms.custom: template-concept
10+
---
11+
12+
# Commit Workflow v2 in Azure Operator Nexus - Network Fabric
13+
14+
**Commit Workflow v2** introduces a modernized and transparent approach for applying configuration changes to **Azure Operator Nexus – Network Fabric (NNF)** resources. This enhanced workflow provides better operational control, visibility, and error handling during the configuration update process.
15+
16+
With this update, users can lock configuration states, preview device-level changes, validate updates, and commit with confidence—overcoming earlier limitations such as the inability to inspect pre/post configurations and difficulty in diagnosing failures.
17+
18+
## Key concepts and capabilities
19+
20+
Commit Workflow v2 is built around a structured change management flow. The following core features are available:
21+
22+
- **Explicit configuration locking:** Users must explicitly lock the configuration of a Network Fabric resource after making changes. This ensures updates are applied in a predictable and controlled manner.
23+
24+
- **Full device configuration preview:** Enables visibility into the exact configuration that will be applied to each device before the commit. This helps validate intent and catch issues early.
25+
26+
- **Commit configuration to devices**
27+
Once validated, changes can be committed to the devices. This final step applies the locked configuration updates across the fabric.
28+
29+
## Prerequisites
30+
31+
Before using Commit Workflow v2, ensure the following environment requirements are met:
32+
33+
### Required versions
34+
35+
* **Runtime version**: `5.0.1` or later is required for Commit Workflow v2.
36+
37+
* **Network Fabric API version**: `2024-06-15-preview`
38+
39+
* **AzCLI version**: `8.0.0.b3` or later
40+
41+
### Supported upgrade paths to runtime version 5.0.1
42+
43+
* **Direct upgrade**: From `4.0.0 → 5.0.1` or From `5.0.0 → 5.0.1`
44+
45+
* **Sequential upgrade**: From `4.0.0 → 5.0.0 → 5.0.1`
46+
47+
> [!Note]
48+
> Additional actions may be required when upgrading from version 4.0.0. Please refer to the [runtime release notes](#) for guidance on upgrade-specific steps.
49+
50+
51+
## Behavior and constraints
52+
53+
Commit Workflow v2 introduces new operational expectations and constraints to ensure consistency and safety in configuration management:
54+
55+
- **Availability & Irreversibility**
56+
57+
Commit Workflow v2 is only available after upgrading to Runtime Version 5.0.1. Once upgraded, reverting to Commit Workflow v1 is not supported.
58+
59+
- **Configuration lock requirements**
60+
61+
Locking is only possible when:
62+
63+
- There is no ongoing commit operation.
64+
65+
- The fabric is not in maintenance or upgrade mode.
66+
67+
- The fabric is in an administrative enabled state.
68+
69+
- **Unsupported during maintenance or upgrade**
70+
71+
Configuration Lock and View Device Configuration are not allowed during maintenance or upgrade windows.
72+
73+
- **Commit is final**
74+
75+
Once a configuration is committed, it cannot be rolled back. Future changes must go through another lock-commit cycle.
76+
77+
### Supported resource actions via Commit workflow v2 (when parent resources are in administrative state – Enabled)
78+
79+
| **Requires Commit Workflow (Impacts Device Config)** | **Does NOT Require Commit Workflow (ARM-level only)** |
80+
| ---------------------------------------------------- | ----------------------------------------------------- |
81+
| Updates to Network Fabric | ISD Creation (L2/L3) |
82+
| Updates to NNI | Network TAP, Neighbor Group creation/updates |
83+
| Updates to Isolation Domains (L2/L3) | IP Prefix / IP Community (unattached) |
84+
| Internal/External Network updates (L3 ISD) | ACL creation not attached to any parent resource |
85+
| Route Policy changes (attached) | NFC creation/updates |
86+
| ACLs (attached to NNI, External, ISD) | Tag updates |
87+
| IP Prefix / Community changes (attached) | Resource delete when disabled and not attached |
88+
| Additional descriptions to Network Devices | Admin actions like enable/disable, upgrade, RMA |
89+
| Network Monitor updates (with Fabric ID) | Deletion of all NNF resources |
90+
91+
92+
### Allowed actions after configuration lock
93+
94+
| **Supported Actions** | **Unsupported Actions** |
95+
| ------------------------------------------------------------------- | --------------------------------------------------- |
96+
| Update NFC | Create/update NNI, ISDs, Internal/External Networks |
97+
| Create/update/delete Network TAP rules, TAP, Neighbor Groups | Modify Route Policies, ACLs (if attached) |
98+
| Create/update IP Prefix / IP Community (unattached) | Modify Network Monitor attached to Fabric |
99+
| Read operations across NNF resources | Delete enabled resources |
100+
| Delete disabled, unattached resources | All admin actions (e.g., enable/disable, RMA) |
101+
| Lock Fabric, View Device Config, Commit Config, Check commit status | Other post-actions must be performed before locking |
102+
103+
104+
## Next steps
105+
106+
[How to use Commit Workflow v2 in Azure Operator Nexus](./howto-use-commit-workflow-v2.md)

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

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
1+
---
2+
title: How to use Commit Workflow v2 in Azure Operator Nexus
3+
description: Learn the process for using Commit Workflow v2 in Nexus Network Fabric
4+
author: sushantjrao
5+
ms.author: sushrao
6+
ms.date: 05/26/2025
7+
ms.topic: how-to
8+
ms.service: azure-operator-nexus
9+
ms.custom: template-how-to, devx-track-azurecli
10+
---
11+
12+
# How to use Commit Workflow v2 in Azure Operator Nexus
13+
14+
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.
15+
16+
## Prerequisites
17+
18+
* Your **Network Fabric must be in `Provisioned` state** and **configuration state must be `Succeeded`**.
19+
20+
* The **fabric and all impacted resources must have admin state set to `Enabled`**.
21+
22+
* You must have **BYOS (Bring Your Own Storage)** configured on the fabric to use the optional validation step.
23+
24+
25+
## Commit Workflow v2 overview
26+
27+
Any **patch operation** on parent resources or **Create/Update/Delete (CUD)** operation on connected child resources will now require an **explicit commit step**. Changes are **batched** until you lock, validate (optional), and commit them.
28+
29+
### Step 1: Update resources
30+
31+
Make patch or CUD operations via Azure CLI, Portal, or ARM template.
32+
Once these changes are made, the fabric's configuration state will change to `Accepted (Pending Commit)`.
33+
34+
#### Example scenarios:
35+
36+
* Create a new **Route Policy** and attach it to **Internal Network 1**
37+
* Create an additional **Internal Network 2**
38+
39+
All these changes will be **batched**, but **not applied** to devices yet.
40+
41+
---
42+
43+
### Step 2: Lock Configuration (Mandatory)
44+
45+
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.
46+
47+
#### Azure CLI Command:
48+
49+
```bash
50+
az networkfabric fabric networkFabricLock \
51+
--type "configuration updates" \
52+
--state "enable" \
53+
--resource-group "example-rg" \
54+
--resource-name "example-fabric"
55+
```
56+
57+
- Successful execution transitions the fabric to a **locked state**.
58+
59+
- Check CLI output for success or failure status.
60+
61+
62+
### Step 3: Validate updates (Optional but recommended)
63+
64+
Validate the configuration using the `ViewDeviceConfiguration` post-action. This shows you how the device configuration will change before you commit.
65+
66+
> [!Important]
67+
> BYOS must be configured on the Network Fabric.
68+
69+
#### Azure CLI Command:
70+
71+
```bash
72+
az networkfabric fabric ViewDeviceConfiguration \
73+
--resource-group "example-rg" \
74+
--resource-name "example-fabric"
75+
```
76+
77+
This provides:
78+
79+
- **Pre-Device Changes**: Current config for all devices (CE, TOR, Management Switches)
80+
81+
- **Post-Device Changes**: Preview of what will be applied after commit
82+
83+
#### Need to Make More Updates?
84+
85+
Unlock the configuration to make further changes, then repeat the lock/validate/commit steps.
86+
87+
#### Unlock Example:
88+
89+
```bash
90+
az networkfabric fabric networkFabricLock \
91+
--type "configuration updates" \
92+
--state "disable" \
93+
--resource-group "example-rg" \
94+
--resource-name "example-fabric"
95+
```
96+
97+
### Step 4: Commit Configuration (Mandatory)
98+
99+
Commit the configuration to apply the batched changes to all relevant fabric devices.
100+
101+
#### Azure CLI Command:
102+
103+
```bash
104+
az networkfabric fabric commitConfiguration \
105+
--resource-group "example-rg" \
106+
--resource-name "example-fabric"
107+
```
108+
109+
- The operation returns a **status**: `Succeeded`, `InProgress`, or `Failed`
110+
111+
- Use CLI polling or Azure Activity Logs to monitor progress
112+
113+
> [Important]
114+
> - This workflow applies **only when the fabric is in Provisioned state** and **admin state is Enabled**. <br>
115+
> - Locking is mandatory before commit; **commit cannot proceed without locking first**. <br>
116+
> - **Rollback is not supported** – any incorrect configuration must be updated and re-committed. <br>
117+
> - Updates outside of this workflow (e.g., to tags or disconnected resources) do **not require commit**. <br>
118+

0 commit comments

Comments
 (0)