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
@@ -50,12 +50,15 @@ Ultimately, the ability for a given service to be upgraded without interruption
50
50
When planning for an upgrade using Azure Operator Service Manager, address the following requirements in advance of upgrade execution to optimize the time spent attempting the upgrade.
51
51
52
52
- Onboard updated artifacts using publisher and/or designer workflows.
53
-
- Publisher, artifact store, network service design group (NSDG), and network function design group (NFDG) are immutabe and cannot change.
54
-
- Changing one of these resources would require deployment of a new NF via put.
53
+
- In most cases, use the existing publisher to host new version artifacts.
54
+
- Using an existing publisher supports `helm upgrade` to update an SNS to a different version.
55
+
- Using a new publisher requies a `helm delete` on the current SNS and then a `helm install` for the new SNS version.
56
+
- Artifact store, network service design group (NSDG), and network function design group (NFDG) are immutabe and cannot change.
57
+
- Changing one of these resources requires deployment of a new SNS.
55
58
- A new artifact manifest is needed to store the new charts and images.
56
-
-For more information, see[onboarding documentation](how-to-manage-artifacts-nexus.md) for details on uploading new charts and images.
59
+
-See[onboarding documentation](how-to-manage-artifacts-nexus.md) for details on uploading new charts and images.
57
60
- A new NFDV, and optionally network service design version (NSDV), is needed.
58
-
-We cover basic changes to the NFDV in the step by step section.
61
+
-NFDV changes can be complex, we cover only basic changes in this article.
59
62
- New NSDV is only required if a new configuration group schema (CGS) version is being introduced.
60
63
- If necessary, new CGS.
61
64
- Required if an upgrade introduces new exposed configuration parameters.
@@ -107,209 +110,40 @@ By default, the reput retries nfApps in the declared update order, unless they a
107
110
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.
108
111
109
112
### Publisher changes
110
-
For the `applicationEnablement` property, the publisher has two options: either provide a default value or parameterize it.
111
-
112
-
#### Sample NFDV
113
-
The NFDV is used by publisher to set default values for applicationEnablement.
113
+
For the `applicationEnablement` property, the publisher has two options: either provide a default value or parameterize it. In the following example, we have provided a default value for `hellotest` which can later be used in an override.
#### Sample configuration group schema (CGS) resource
172
-
The CGS is used by the publisher to require a `roleOverrideValues` variable to be provided by Operator at run-time. `roleOverrideValues` can include nondefault settings for `applicationEnablement`.
173
-
174
-
```json
175
-
{
176
-
"type": "object",
177
-
"properties": {
178
-
"location": {
179
-
"type": "string"
180
-
},
181
-
"nfviType": {
182
-
"type": "string"
183
-
},
184
-
"nfdvId": {
185
-
"type": "string"
186
-
},
187
-
"helloworld-cnf-config": {
188
-
"type": "object",
189
-
"properties": {
190
-
"role1releasenamespace": {
191
-
"type": "string"
192
-
},
193
-
"role1releasename": {
194
-
"type": "string"
195
-
},
196
-
"role2releasenamespace": {
197
-
"type": "string"
198
-
},
199
-
"role2releasename": {
200
-
"type": "string"
201
-
},
202
-
"roleOverrideValues1": {
203
-
"type": "string"
204
-
},
205
-
"roleOverrideValues2": {
206
-
"type": "string"
207
-
}
208
-
},
209
-
"required": [
210
-
"role1releasenamespace",
211
-
"role1releasename",
212
-
"role2releasenamespace",
213
-
"role2releasename",
214
-
"roleOverrideValues1",
215
-
"roleOverrideValues2"
216
-
]
217
129
}
218
-
},
219
-
"required": [
220
-
"nfviType",
221
-
"nfdvId",
222
-
"location",
223
-
"helloworld-cnf-config"
224
-
]
225
130
}
226
131
```
227
132
228
133
### Operator changes
229
-
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.
230
-
231
-
#### Sample configuration group value (CGV) resource
232
-
The CGV is used by the operator to set the `roleOverrideValues` variable at run-time. `roleOverrideValues` include nondefault settings for `applicationEnablement`.
134
+
Operators inherit default `applicationEnablement` values as defined by the NFDV. If `applicationEnablement` is parameterized, then it can be passed through the `deploymentValues` property at runtime using the CGV. `roleOverrideValues` specifies a nondefault setting for `applicationEnablement`.
The NF ARM template is used by operator to submit the `roleOverrideValues` variable, set by CGV, to the resource provider (RP). The operator can change the `applicationEnablement` setting in CGV, as needed, and resubmit the same NF ARM template, to alter behavior between iterations.
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.
0 commit comments