You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This article introduces Azure Operator Service Manager (AOSM) safe upgrade practices (SUP). This feature set enables an end user to safely execute complex upgrades of CNF workloads hosted on Azure Operator Nexus, in compliance with partner ISSU requirements, where applicable. Look for future articles in these services to expand on SUP features and capabilities.
14
+
This article introduces Azure Operator Service Manager (AOSM) safe upgrade practices (SUP). This feature set enables an end user to safely execute complex upgrades of Container Network Function (CNF) workloads hosted on Azure Operator Nexus, in compliance with partner In Service Software Upgrade (ISSU) requirements, where applicable. Look for future articles in these services to expand on SUP features and capabilities.
15
15
16
16
## Introduction
17
17
A given network service supported by Azure Operator Service Manager will be composed of one to many container based network functions (CNFs) which, over time, will require software updates. For each update, it is necessary to run one to many helm operations, upgrading dependent network function applications (NfApps), in a particular order, in a manner which least impacts the network service. At Azure Operator Service Manager, Safe Upgrade Practices represents a set of features, which can automate the CNF operations required to update a network service on Azure Operator Nexus.
18
18
19
19
* SNS Reput update - Execute helm upgrade operation across all NfApps in NFDV.
20
20
* Nexus Platform - Support SNS reput operations on Nexus platform targets.
21
-
* Operation Timeouts - Ability to set operational timeouts for each NfApp operation.
21
+
* Operation Time-outs - Ability to set operational time-outs for each NfApp operation.
22
22
* Synchronous Operations - Ability to run one serial NfApp operation at a time.
23
23
* Pause On Failure - Based on flag, set failure behavior to rollback only last NfApp operation.
24
24
* Single Chart Test Validation - Running a helm test operation after a create or update.
@@ -27,7 +27,7 @@ A given network service supported by Azure Operator Service Manager will be comp
27
27
## Upgrade approach
28
28
To update an existing Azure Operator Service Manager site network service (SNS), the Operator executes a reput update request against the deployed SNS resource. Where the SNS contains CNFs with multiple NfApps, the request is fanned out across all NfApps defined in the network function definition version (NFDV). By default, in the order, which they appear, or optionally in the order defined by UpdateDependsOn parameter.
29
29
30
-
For each NfApp, the reput update request supports increasing a helm chart version, adding/removing helm values and/or adding/removing any NfApps. Timeouts can be set per NfApp, based on known allowable runtimes, but NfApps can only be processed in serial order, one after the other. The reput update implements the following processing logic:
30
+
For each NfApp, the reput update request supports increasing a helm chart version, adding/removing helm values and/or adding/removing any NfApps. Time-outs can be set per NfApp, based on known allowable runtimes, but NfApps can only be processed in serial order, one after the other. The reput update implements the following processing logic:
31
31
32
32
* NfApps are processed following either updateDependsOn ordering, or in the sequential order they appear.
33
33
* NfApps with parameter "applicationEnabled" set to disable are skipped.
@@ -69,7 +69,7 @@ Helm chart versions can be updated, or Helm values can be updated or parameteriz
69
69
UpdateDependsOn is an NFDV parameter used to specify ordering of NfApps during update operations. If UpdateDependsOn is not provided, serial ordering of CNF applications, as appearing in the NFDV is used.
70
70
71
71
### Update NFDV for desired upgrade behavior
72
-
Make sure to set any desired CNF application timeouts, the atomic parameter, and rollbackOnTestFailure parameter. It may be useful to change these parameters over time as more confidence is gained in the upgrade.
72
+
Make sure to set any desired CNF application time-outs, the atomic parameter, and rollbackOnTestFailure parameter. It may be useful to change these parameters over time as more confidence is gained in the upgrade.
73
73
74
74
### Issue SNS reput
75
75
With onboarding complete, the reput operation is submitted. Depending on the number, size and complexity of the NfApps, the reput operation could take some time to complete (multiple hours).
@@ -90,7 +90,7 @@ After fixing the failed NfApp, but before attempting an upgrade retry, consider
90
90
By default, the reput retries NfApps in the declared update order, unless they are skipped using applicationEnablement flag.
91
91
92
92
## How to use applicationEnablement
93
-
In the NFDV resource, under deployParametersMappingRuleProfile there is the property applicationEnablement of type enum, which takes values: Unknown, Enabled, or disabled. It can be used to exclude NfApp operations during NF deployment.
93
+
In the NFDV resource, under deployParametersMappingRuleProfile there is the property applicationEnablement of type enum, which takes values: Unknown, Enabled, or disabled. It can be used to exclude NfApp operations during network function (NF) deployment.
94
94
95
95
### Publisher changes
96
96
For the applicationEnablement property, the publisher has two options: either provide a default value or parameterize it.
@@ -155,7 +155,7 @@ The NFDV is used by publisher to set default values for applicationEnablement.
155
155
```
156
156
157
157
#### Sample configuration group schema (CGS) resource
158
-
The CGS is used by publisher to require the roleOverrideValues variable(s) to be provided by Operator at runt-time. These roleOverrideValues can include non-dedfault settings for applicationEnablement.
158
+
The CGS is used by the publisher to require a roleOverrideValues variable to be provided by Operator at run-time. RoleOverrideValues can include non-default settings for applicationEnablement.
159
159
160
160
```json
161
161
{
@@ -212,10 +212,10 @@ The CGS is used by publisher to require the roleOverrideValues variable(s) to be
212
212
```
213
213
214
214
### Operator changes
215
-
Operators inherity default applicationEnablement values as defined by the NFDV. If applicationEnablement is parameterized in CGS, then it must be passed through the deploymentValues property at runtime.
215
+
Operators inherit default applicationEnablement values as defined by the NFDV. If applicationEnablement is parameterized in CGS, then it must be passed through the deploymentValues property at runtime.
216
216
217
217
#### Sample configuration group value (CGV) resource
218
-
The CGV is used by operator to set the roleOverrideValues variable(s) at runt-time. The roleOverrideValues includes a non-dedfault settings for applicationEnablement.
218
+
The CGV is used by the operator to set the roleOverrideValues variable at run-time. RoleOverrideValues include non-default settings for applicationEnablement.
219
219
220
220
```json
221
221
{
@@ -296,6 +296,46 @@ The NF ARM template is used by operator to submit the roleOverrideValues variabl
296
296
}
297
297
```
298
298
299
+
## How to skip NfApps which have no changes
300
+
The SkipUpgrade feature is designed to optimize the time taken for CNF upgrades. When the publisher enables this flag in the `RoleOverrideValues` under `UpgradeOptions`, the AOSM service layer performs certain prechecks, to determine whether an upgrade for a specific `NFApplication` can be skipped. If all precheck criteria are met, the upgrade is skipped for that application. Otherwise, an upgrade is executed at the cluster level.
301
+
302
+
### PreCheck Criteria
303
+
An upgrade can be skipped if all the following conditions are met:
304
+
1. The `NFApplication` provisioning state is Succeeded.
305
+
2. There is no change in the Helm chart name or version.
306
+
3. There is no change in the Helm values.
307
+
308
+
### Enabling or Disabling the SkipUpgrade Feature
309
+
The SkipUpgrade feature is **disabled by default**. If this optional parameter is not specified in `RoleOverrideValues` under `UpgradeOptions`, CNF upgrades proceed in the traditional manner, where the `NFApplications` are upgraded at the cluster level.
310
+
311
+
#### Enabling SkipUpgrade withing Network Function Resource
312
+
To enable the SkipUpgrade feature via `RoleOverrideValues`, refer to the following example.
- The `skipUpgrade` flag is enabled. If the upgrade request for `hellotest` meets the precheck criteria, the upgrade will be skipped at the service level.
336
+
-**NfApplication: `runnerTest`**
337
+
- The `skipUpgrade` flag is not specified. Therefore, `runnerTest` executes a traditional Helm upgrade at the cluster level, even if the precheck criteria are met.
338
+
299
339
## Support for in service upgrades
300
340
Azure Operator Service Manager, where possible, supports in service upgrades, an upgrade method which advances a deployment version without interrupting the service. However, the ability for a given service to be upgraded without interruption is a feature of the service itself. Consult further with the service publisher to understand the in-service upgrade capabilities.
0 commit comments