Introduction
This wiki is meant to detail the steps to automate the Network Slicing use case testing using the O-RAN-SC SMO package.
...
https://wiki.onap.org/display/DW/E2E+network+slicing+use+case+-+Option2
There are in general 4 steps to run the use case, as listed below.
Currently the first 2 steps are completed, but the last 2 steps are still in progressionunder development.
- Deploy ONAP components using SMO starting script
- Run use case preparation scripts to configure all the components
- Starting needed simulators
- Run test script and verify the result
The source code are stored under SMO package on ORAN gerrit in the "it/dep" repo (currently not in gerrit repo yet, will be uploaded soon):
step 1: Deploy ONAP components using SMO starting script
Start the platform for the use case, we could use the SMO starting scripts.
If you don't have an idea about what SMO starting scripts are, please have a read of the SMO package introduction and watch the attached videos first.
...
In general, you can run the scripts under layer-0 to install the needed software on your lab.
Then trigger script under layer-1 to build all the needed helm chart.
...
The command above will take configuration parameters from onap-override.yaml under folder helm-override/network-slicing.
If you want different configurations, please update them configuration values, then you must update those values in the onap-override.yaml file.
...
The deployment will take about 1 hour to be fully started and stabilized, since it involves lots of components.
! Before going to the next step, please make sure all the components are running OK. !
Note: Network Slicing use case involves deploying lots of components. Depends Depending on the system you are using, the no. number of pods you have started to start might exceed the max-pod allowance of the system, which will cause a lots of pods to be in status Pending. If using "kubectl describe" to show the details of the pod, you will see error message of "too many pods".
Increasing the max-pod number to 200 will solve the issue. Different system set max pod in different ways. With microk8s you can open file /var/snap/microk8s/current/args/kubelet, add the line "--max-pods=200" at the end of the file, restart the service with command service snap.microk8s.daemon-kubelite restart and verify whether the date has been updated with command kubectl describe node <node_value> | grep -i capacity -A 13.
step 2: Run use case preparation scripts to configure all the components
The preparation scripts are python scripts, based on the ONAP pythonsdk framework. The detailed introduction of the framework can be found in the SMO package introduction.
The scripts regarding dedicated to the network slicing locates are located in folder test/pythonsdk/src/orantests/network_slicing.
...
The command will trigger the main script test_network_slicing.py, which further in turn triggers the preparation script of each component.
The whole preparation process will configure the components and also verifies a bit whether the configuration was done successfully at the end of each step.
The whole process may take about 1 hour to complete. You can monitor the progress using the log file pythonsdk.debug.log at located in the folder network_slicing/preparation.
...
If things goes wrong, please read the logs to identify which part has go wrong and try to fix that step manually.
Then you can update the test_network_slicing.py, disable steps that are already complete, and replay the tox command to complete the rest of the configuration.
...
In case it failed in the middle of the SDC template creation, please update the sdc_template_suffix variable inside the test_network_slicing.py and then rerun the script with tox command.
Since SDC doesn't support creating template with the same name, neither deleting of any templates, you have to add a suffix to the original name to create template with a new name.
step 3: Starting needed simulators
Network Slicing Option2 use case involves 3 simulators: external core NSSMF simulator, ACTN simulator and external RAN NSSMF simulator.
SMO packages prepares the lab using helm charts, but unfortunately there are no helm chart available yet for those 3 simulators, so they should be started manually at this moment.
It is in our plan to create helm chart for those 3 simulators and put them under tests_oom folder, so that they could be deployed easily using SMO starting script in the future.
which are under tests_oom folder.
When starting the testing script, the needed simulators will be started at the beginning. After the tests is completed, the simulators will be deleted.
step 4 : Run test script and verify the result
When typing the tox command, it first runs the preparation scripts and then triggers the real testing script.
The real testing script is written in file test_network_slicing.py under method test_network_slicing_option2.
It will trigger the network slicing use case and using assert to verify the result.
At this moment, the method is still empty. We are still progressing in the testing script.
If you want to continue the Network Slicing Option2 use case test, please run it manually.
Currently known issues
Currently the SMO package is based on the ONAP oom Jakarta release. There's already some known issue issues regarding the Network Slicing related code.
...
Restart the so-bpmn-infra pod with command "kubectl delete pod <onap-so-bpmn-infra-pod-name> -n onap"
Demos:
| View file | ||||
|---|---|---|---|---|
|
| View file | ||||
|---|---|---|---|---|
|