Skip to content

Commit d07d4d4

Browse files
authored
Update best-practices-onboard-deploy.md
update for ordering behavior
1 parent 40ef012 commit d07d4d4

File tree

1 file changed

+74
-0
lines changed

1 file changed

+74
-0
lines changed

articles/operator-service-manager/best-practices-onboard-deploy.md

Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -313,3 +313,77 @@ For the cert-manager operator, our current deployed version is 1.14.5. Users sh
313313

314314
For the CRD resources, our current deployed version is 1.14.5. Users should test for compatibility with this version. Since management of a common cluster CRD is something typically handled by a cluster administrator, we are working to enable CRD resource upgrades via standard Nexus Add-on process.
315315

316+
## NfApp Sequential Ordering Behavior
317+
318+
### Overview
319+
320+
By default, containerized network function applications (NfApps) are installed or updated based on the sequential order in which they appear in the network function design version (NFDV). For delete, the NfApps are deleted in the reverse order sepcified. Where a publisher needs to define specific ordering of NfApps, different from the default, a dependsOnProfile is used to define a unique sequence for install, update and delete operations.
321+
322+
### How to use dependsOnProfile
323+
324+
A publisher can use the dependsOnProfile in the NFDV to control the sequence of helm executions for NfApps. Given the following example, on install operation the NfApps will be deployed in the following order: dummyApplication1, dummyApplication2, then dummyApplication. On update operation, the NfApps will be updated in the following order: dummyApplication2, dummyApplication1, then dummyApplication. On delete operation, the NfApps will be deleted in the following order: dummyApplication2, dummyApplication1, then dummyApplication.
325+
326+
```json
327+
{
328+
"location": "eastus",
329+
"properties": {
330+
"networkFunctionTemplate": {
331+
"networkFunctionApplications": [
332+
{
333+
"dependsOnProfile": {
334+
"installDependsOn": [
335+
"dummyApplication1",
336+
"dummyApplication2"
337+
],
338+
"uninstallDependsOn": [
339+
"dummyApplication1"
340+
],
341+
"updateDependsOn": [
342+
"dummyApplication1"
343+
]
344+
},
345+
"name": "dummyApplication"
346+
},
347+
{
348+
"dependsOnProfile": {
349+
"installDependsOn": [
350+
],
351+
"uninstallDependsOn": [
352+
"dummyApplication2"
353+
],
354+
"updateDependsOn": [
355+
"dummyApplication2"
356+
]
357+
},
358+
"name": "dummyApplication1"
359+
},
360+
{
361+
"dependsOnProfile": null,
362+
"name": "dummyApplication2"
363+
}
364+
],
365+
"nfviType": "AzureArcKubernetes"
366+
},
367+
"networkFunctionType": "ContainerizedNetworkFunction"
368+
}
369+
}
370+
```
371+
372+
### Common Errors
373+
374+
As of today, if dependsOnProfile provided in the NFDV is invalid, the NF operation will fail with a validation error. The validation error message is shown in the operation status resource and looks similar to the following example.
375+
376+
```json
377+
{
378+
"id": "/providers/Microsoft.HybridNetwork/locations/EASTUS2EUAP/operationStatuses/ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
379+
"name": "ca051ddf-c8bc-4cb2-945c-a292bf7b654b*C9B39996CFCD97AB3A121AE136ED47F67BB13946C573EF90628C47628BC5EF5F",
380+
"resourceId": "/subscriptions/4a0479c0-b795-4d0f-96fd-c7edd2a2928f/resourceGroups/xinrui-publisher/providers/Microsoft.HybridNetwork/networkfunctions/testnfDependsOn02",
381+
"status": "Failed",
382+
"startTime": "2023-07-17T20:48:01.4792943Z",
383+
"endTime": "2023-07-17T20:48:10.0191285Z",
384+
"error": {
385+
"code": "DependenciesValidationFailed",
386+
"message": "CyclicDependencies: Circular dependencies detected at hellotest."
387+
}
388+
}
389+
```

0 commit comments

Comments
 (0)