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 describes hww Azure Operator Service Manager (AOSM) users can run tests on deployed network functions (NFs) as part install or upgrade operations. When enabledd, each network function application (nfApp) will be tested after completion of the install or upgrade opreation. A successful result of the nfApp test will be required for the NF operation status to report successful.
12
+
This article describes how Azure Operator Service Manager (AOSM) can run tests on deployed network functions (NFs) as part install or upgrade operations. When enabled, each network function application (nfApp) will be tested after install or upgrade completion. A successful result of all nfApp tests are required for the NF operation status to complete successfully.
13
13
14
14
## Overview
15
15
This feature's scope is to run helm tests as part of the network function install or upgrade operations.
16
-
* Users will author their own tests and include within helm package during NF onboarding.
17
-
* Only where enabled, AOSM will execute these helm tests on each nfApp.
18
-
* Upon test success, AOSM will proceed to the next nfApp.
19
-
* Upon test failure, AOSM will honor `RollbackOnTestFail` flag to determine if the nfApp will be rolled back.
20
-
* The parent NF operation will terminate with failure if any nfApp fails a user configured test.
21
-
* Upon parent failure, AOSM will honor the configured method of NF failure control, either `pause-on-failure` or `rollback-on-failure`.
16
+
* Users author their own tests and include them within the helm package during NF onboarding.
17
+
* Only where enabled, AOSM executes these helm tests on each nfApp.
18
+
* Upon test success, AOSM proceeds to the next nfApp.
19
+
* Upon test failure, AOSM honors `RollbackOnTestFail` flag to determine if the nfApp is rolled back.
20
+
* The parent NF operation terminates with failure if any nfApp fails a configured test.
21
+
* Upon parent failure, AOSM honors the configured method of NF failure control, either `pause-on-failure` or `rollback-on-failure`.
22
22
23
23
> [!NOTE]
24
-
> * Helm Test is only supported as part of the install/upgrade operation and cannot be run separately.
24
+
> * Helm Test is only supported as part of the install or upgrade operation and can't be run separately.
25
25
26
26
## Authoring helm tests
27
-
Helm tests are authored by the owner of the helm charts. The helm tests are defined in the helm chart under the folder: `<ChartName>/Templates/`. Each test includes a job definition that specifies a container environment and command to run. The container environment should exit successfully for a test to be considered a success. The job definition must include the Helm test hook annotation `(helm.sh/hook: test)` to be recognized as a test by Helm.
27
+
The publisher is responsible for authoring the helm tests during construction of the helm charts. The helm tests are defined in the helm chart under the folder: `<ChartName>/Templates/`. Each test includes a job definition that specifies a container environment and command to run. The container environment should exit successfully for a test to be considered a success. The job definition must include the helm test hook annotation `(helm.sh/hook: test)` to be recognized as a test by helm.
28
28
29
29
## Enable helm tests during operations
30
-
AOSM provides a set of configurable install and upgrade options for each component under a NF. These existing options are extended with a new configurable 'TestOptions` parameter. This will give the uses the ability to specify TestOptions per nfApp and as per the type of operation. Following are the parameters available under the TestOptions bag:
30
+
AOSM provides a set of configurable install and upgrade options for each component under an NF. These existing options are extended with a new 'testOptions` parameter. This gives the user the ability to specify testOptions per nfApp and as per the type of operation. The following parameters are supported by the testOptions flag:
31
31
32
32
* enable
33
-
*This is a bool flag that will enable/disable helm test on a component after install/upgrade.
33
+
*Enables or disables the helm test on a nfApp after install or upgrade completes.
34
34
* Default value is false.
35
35
* timeout
36
-
*This parameter takes an int that represents test timeout in minutes.
36
+
*Takes a value that represents the test time-out in minutes.
37
37
* Default value is 20 minutes.
38
38
* rollbackOnTestFailure
39
-
*This is a bool flag that will enable/disable component rollback on helm test failure.
39
+
*Enables or disables component rollback on helm test failure.
40
40
* Default value is true.
41
41
* filter
42
-
*This is a list of strings and each string in the list represents a test name. This parameter will allow users to run a subset of defined tests in the chart
43
-
*No filter is applied by default.
42
+
*Allows for a method to run only a subset of chart tests. Accepts a list of strings where each string in the list represents a test nameto include.
43
+
*Default value is no filter.
44
44
45
45
## Exposing helm test control via parameters
46
-
Users already can use `RoleOverrideValues` parameter in a NF payload to specify `InstallOptions` and `UpgradeOptions`. Now the `InstallOptions` and `UpgradeOptions` will be extended to hold `TestOptions`. Thus, `TestOptions` can be specified for each component under a NF and each method of operation. Following is an example of roleOverrideValues to be specified in the NF Payload to specify InstallOptions (inlcuding TestOptions) and UpgradeOptions (including TestOptions) for a component named: application1-
46
+
Users already can use the NF payload parameter `roleOverrideValues` to specify settings for `installOptions` and `upgradeOptions`. These fields are now extended to include settings for `testOptions` which can be specified for each nfApplication and each operation method. See the following example of `roleOverrideValues` usage where the NF Payload speificies `installOptions` and `upgradeOptions` including `TestOptions` for a component named `application1`.
47
+
48
+
## roleOverrideValues escaped example:
49
+
Following is an escaped example `roleOverrideValues` with `testOptions` under `installOptions` and `upgradeOptions` for a component named `application1`. This example uses a `filter` to execute only those test which match the string provided.
Following is an unescaped example `roleOverrideValues` NF Payload with `testOptions` under `installOptions` and `upgradeOptions` for a component named `hellotest`. This example uses a `filter` to execute only those test which match the string provided.
54
58
```
55
-
Uescaped Version:
56
-
"roleOverrideValues": [
57
-
"{"name":"hellotest",
58
-
"deployParametersMappingRuleProfile":
59
-
{"helmMappingRuleProfile":
60
-
{
61
-
"options":
62
-
{
63
-
"installOptions":
64
-
{
65
-
"atomic":"true",
66
-
"wait":"true",
67
-
"timeout":"1"
68
-
“testOptions”:
69
-
{
70
-
“enable”: “true”,
71
-
“timeout”: “10”,
72
-
“rollbackOnTestFailure”: “true”,
73
-
"filter”: [“test1”, “test2”]
74
-
}
75
-
},
76
-
"upgradeOptions":
77
-
{
78
-
"atomic":"true",
79
-
"wait":"true",
80
-
"timeout":"2",
81
-
“testOptions”:
82
-
{
83
-
“enable”: “true”,
84
-
“timeout”: “10”,
85
-
“rollbackOnTestFailure”: “true”,
86
-
"filter”: [“test1”, “test2”]
87
-
} } } } } }" ]
59
+
"roleOverrideValues": ["{
60
+
"name":"hellotest",
61
+
"deployParametersMappingRuleProfile": {
62
+
"helmMappingRuleProfile": {
63
+
"options": {
64
+
"installOptions": {
65
+
"atomic":"true",
66
+
"wait":"true",
67
+
"timeout":"1"
68
+
“testOptions”: {
69
+
“enable”: “true”,
70
+
“timeout”: “10”,
71
+
“rollbackOnTestFailure”: “true”,
72
+
"filter”: [“test1”, “test2”] } },
73
+
"upgradeOptions": {
74
+
"atomic":"true",
75
+
"wait":"true",
76
+
"timeout":"2",
77
+
“testOptions”: {
78
+
“enable”: “true”,
79
+
“timeout”: “10”,
80
+
“rollbackOnTestFailure”: “true”,
81
+
"filter”: [“test1”, “test2”] } } } } } }"
82
+
]
88
83
```
89
-
## Example of TestOptions usage
90
-
Following is an example NF Payload with TestOptions under InstallOptions and UpgradeOptions for a component named: application1
84
+
85
+
## NF payload complete example
86
+
Following is an example NF Payload with `testOptions` under `installOptions` and `upgradeOptions` for a component named `application1`. This example uses a `filter` to execute only those test which match the string provided.
0 commit comments