Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Commit workflow v2 introduces a modernized and transparent approach for applying configuration changes to Azure Operator Nexus - Network Fabric resources. This enhanced workflow provides better operational control, visibility, and error handling during the configuration update process.
With this update, you can lock configuration states, preview device-level changes, validate updates, and commit with confidence. You can overcome earlier limitations, such as the inability to inspect pre- or post-configurations and difficulty in diagnosing failures.
Key concepts and capabilities
Commit workflow v2 is built around a structured change management flow. The following core features are available:
- Explicit configuration locking: Requires you to explicitly lock the configuration of a Network Fabric resource after changes were made. This process ensures that updates are applied in a predictable and controlled manner.
- Full device configuration preview: Enables visibility into the exact configuration that's applied to each device before the commit. This step helps validate intent and catch issues early.
- Commit configuration to devices: Commits changes to devices after validation. 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, and upgrade phases for stability.
Prerequisites
Before you use commit workflow v2, ensure that the following environment requirements are met.
Commit workflow-compatible versions
The commit workflow version supported depends on the combination of Network Fabric runtime, portal release version, and API version in use. Use the following table to identify which commit workflow applies to your environment.
| Network Fabric version | Release version | API versions | Commit workflow version |
|---|---|---|---|
| 3.0, 4.0, 5.0 | 8.1 and earlier | 2024-06-15-preview 2024-02-15-preview 2023-06-15-stable |
Commit workflow v1 |
| 5.0.0 | 8.2, 8.3 | 2024-06-15-preview 2024-02-15-preview 2023-06-15-stable |
Commit workflow v1 |
| 5.0.0 | 9.0 | 2024-06-15-preview | Commit workflow v1 |
| 5.0.1 | 8.2, 8.3 | 2024-06-15-preview | Commit workflow v2 |
| 6.0 and later | 9.0 and later | 2024-06-15-preview and later | Commit workflow v2 |
Note
If you run Network Fabric version 5.0.1 or later, commit workflow v2 is required. Commit workflow v1 is no longer supported.
Required versions
If you're unsure which commit workflow version applies to your setup, refer to the commit workflow-compatible versions:
- Runtime version: Version 5.0.1 or later is required for commit workflow v2.
- Network Fabric API version: Version 2024-06-15-preview.
- AzCLI version: Version 8.0.0.b3 or later.
Supported upgrade paths to runtime version 5.0.1
- Direct upgrade: From 4.0.0 to 5.0.1 or from 5.0. to 5.0.1
- Sequential upgrade: From 4.0.0 to 5.0.0 to 5.0.1
Note
More actions might be required when you upgrade from version 4.0.0. For guidance on upgrade-specific steps, refer to the Runtime release notes.
Behavior and constraints
Commit workflow v2 introduces new operational expectations and constraints to ensure consistency and safety in configuration management.
Availability and locking rules
Available only on runtime version 5.0.1+. Downgrade to v1 isn't supported.
Locking is allowed only when:
- No commit is in progress.
- Network Fabric isn't under maintenance or upgrade.
- Network Fabric is in an administrative-enabled state.
Unsupported during maintenance or upgrade
The Lock, ViewDeviceConfiguration, and related post-actions operations aren't allowed during maintenance or upgrade windows.
Commit finality
After changes are committed, they can't be rolled back. Any further edits require a new lock-validate-commit cycle.
Discard batch behavior
The
discard-commit-batchoperation:- Reverts all Azure Resource Manager resource changes to their last known good state.
- Updates administrative/configuration states (for example, external/internal networks become disabled and rejected).
- Doesn't delete resources. You must delete them manually if you want.
- Enables further patching to reapply changes.
When the discard batch action is performed:
- The administrative state of internal/external network resources moves to disabled. Their configuration state moves to rejected. The resources aren't deleted automatically. A separate delete operation is required for removal.
- The enabled Network Monitor resources attached to a fabric can't be attached to another fabric unless first detached and committed.
- The configuration state moves to rejected for Network Monitor resources that are in a disabled administrative state (in commit queue). You can reapply updates (PUT/patch) and commit again to enable.
Resource update restrictions
Post-lock: Only a limited set of create, update, and delete (CUD) actions are supported. Examples are unattached access control lists (ACLs) or test access point (TAP) rules.
Resources that affect devices, such as 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 the enabled administrative state)
| Supported resource actions that require commit workflow | Unsupported resource actions that don't require commit workflow |
|---|---|
| All resource updates that affect device configuration: • Updates to the Network Fabric resource. • Updates to NNI. • Updates to ISD (layer 2 and layer 3). • Creation and updates to internal/external networks of enabled layer 3 ISD. • Addition, update, or removal of route policy in internal/external, ISD, and NNI resources. • Addition, update, or removal of IPPrefix, IPCommunity, and IPExtendedCommunity resources when attached to route policy or Network Fabric.• Addition, update, or removal of ACLs to internal/external, ISD, and NNI resources. • Addition, update, or removal of Network Fabric resource in Network Monitor resource. • Other description updates to network device properties. • Creation of multiple NNIs. |
Creation and updates of resources that don't affect device configuration: • Creation of ISD (layer 2 and layer 3). • Network Fabric Controller (NFC) creation and updates. • Creation and updates to network TAP rules, network TAP, and neighbor groups. • Creation and updates to network TAP rules, network TAP, and neighbor groups. • Creation of new route policy and connected resources ( IPPrefix, IPCommunity, and IPExtendedCommunity).• Update of route policy and connected resources when not attached to ISD, internal/external, and NNI. • Creation and update of a new ACL, which isn't attached. Resource Manager resource updates only: • Tag updates for all supported resources. Other administrative actions and post actions that manage lifecycle events: • Enable or disable ISD, Return Material Authorization, upgrade, all administrative actions (enable or disable), and serial number update. • Deletion of all Azure Operator Nexus - Network Fabric resources. |
Allowed actions after configuration lock
The following table shows supported actions after configuration lock is enabled on the fabric. The actions are categorized by type and support status.
Supported and unsupported actions after configuration lock
| Actions | Supported resource actions when the fabric is under configuration lock | Unsupported resource actions when the fabric is under configuration lock |
|---|---|---|
| Resource actions (CUD) | - NFC (only update). - Network TAP rules, network TAP, and neighbor group (CUD). - ACL (create or update) when not attached to parent resource. - Network Monitor created without the Network Fabric ID. - Creation or update of IPPrefix, IPCommunityList, and IPExtendedCommunity when not attached to route policy.- Read of all Azure Operator Nexus - Network Fabric resources. - Deletion of disabled resources and not attached to any parent resources. |
- No CUD operations allowed on: • NNI. • ISDs (layer 2 and layer 3). • Internal/external networks (additions or updates). • Route policy, IPPrefix, IPCommunityList, and IPExtendedCommunity.• ACLs when attached to parent resources (for example, NNI and external network). • Network Monitor when attached to Network Fabric. • Deletion of all enabled resources. |
| Post actions | - Lock Network Fabric (administrative state). - View device configuration. - Commit configuration. - ARMConfig Diff. - Commit batch status. |
- All other post actions are blocked and must be done before enabling configuration lock. |
| Service actions/Geneva actions | - Not available. | - All service actions are blocked. |