...
In order to deploy such an instance, we can follow the ONAP deployment guide in this link: https://docs.onap.org/en/dublinelalto/submodules/oom.git/docs/oom_quickstart_guide.html#quick-start-label
As we can see from the guide, we can use an override file that helps us customize our ONAP deployment, without modifying the OOM Folder, so you can download this override file here, that includes the necessary components mentioned above.
...
Code Block | ||
---|---|---|
| ||
root@olc-dublin-rancher:~# cd oom/kubernetes/robot/ root@olc-dublin-rancher:~/oom/kubernetes/robot# ./demo-k8s.sh onap init_customer Number of parameters: 2 KEY: init_customer ++ kubectl --namespace onap get pods ++ sed 's/ .*//' ++ grep robot + POD=onap-robot-robot-6dd6bfbd85-nl29n + ETEHOME=/var/opt/ONAP ++ kubectl --namespace onap exec onap-robot-robot-6dd6bfbd85-nl29n -- bash -c 'ls -1q /share/logs/ | wc -l' + export GLOBAL_BUILD_NUMBER=3 + GLOBAL_BUILD_NUMBER=3 ++ printf %04d 3 + OUTPUT_FOLDER=0003_demo_init_customer + DISPLAY_NUM=93 + VARIABLEFILES='-V /share/config/vm_properties.py -V /share/config/integration_robot_properties.py -V /share/config/integration_preload_parameters.py' + kubectl --namespace onap exec onap-robot-robot-6dd6bfbd85-nl29n -- /var/opt/ONAP/runTags.sh -V /share/config/vm_properties.py -V /share/config/integration_robot_properties.py -V /share/config/integration_preload_parameters.py -d /share/logs/0003_demo_init_customer -i InitCustomer --display 93 Starting Xvfb on display :93 with res 1280x1024x24 Executing robot tests at log level TRACE ============================================================================== Testsuites ============================================================================== Testsuites.Demo :: Executes the VNF Orchestration Test cases including setu... ============================================================================== Initialize Customer | PASS | ------------------------------------------------------------------------------ Testsuites.Demo :: Executes the VNF Orchestration Test cases inclu... | PASS | 1 critical test, 1 passed, 0 failed 1 test total, 1 passed, 0 failed ============================================================================== Testsuites | PASS | 1 critical test, 1 passed, 0 failed 1 test total, 1 passed, 0 failed ============================================================================== Output: /share/logs/0003_demo_init_customer/output.xml Log: /share/logs/0003_demo_init_customer/log.html Report: /share/logs/0003_demo_init_customer/report.html root@olc-dublin-rancher:~/oom/kubernetes/robot# |
Unresolved Composite Data:
We need to update the self-serve-unresolved-composite-data.json and self-serve-unresolved-composite-data.xml Directed Graphs in SDNC.
We can do this by downloading the files from here:
Then we can login to SDNC DG Builder GUI at http://<onap_ip_address>:30203 and using username/password dguser/test123.
After that we import the json into a new canvas, and upload the DG, so that SDNC uses the correct version.
SO Orchestration Transition Table Updates:
Code Block |
---|
INSERT INTO `catalogdb`.`orchestration_status_state_transition_directive` (`RESOURCE_TYPE`, `ORCHESTRATION_STATUS`, `TARGET_ACTION`, `FLOW_DIRECTIVE`)
VALUES
('VNF', 'CONFIGURED', 'ACTIVATE', 'CONTINUE'); |
Retry for ConfigDeployVnfBB:
The vLB VM will download source code and will build the netconf simulator that will receive the configuration updates from CDS. This process might take more than 5 minutes.
Due to a default 5 minute timeout value in Camunda BPMN Execution Engine, this means the ConfigDeployVnfBB might fail, which will break the E2E automation of the instantiation.
Thus, we need to tell SO that if ConfigDeployVnfBB fails, it should retry ConfigDeployVnfBB.
We can do this by adding an entry in the SO CATALOG DB rainy_day_handler_macro table, as shown below:
We can do this by connecting to the SO CATALOG DB, and running the following SQL command:
Code Block | ||||
---|---|---|---|---|
| ||||
INSERT INTO rainy_day_handler_macro (FLOW_NAME, SERVICE_TYPE, VNF_TYPE, ERROR_CODE, WORK_STEP, POLICY, SECONDARY_POLICY)
VALUES
('ConfigDeployVnfBB', '*', '*', '*', '*' , 'Retry', 'Abort');
|
Also, in order to allow SO to retry the ConfigDeployVnfBB if it fails the 1st time, we can update the override.yaml file for the SO BPMN INFRA chart in OOM like below:
Code Block | ||||
---|---|---|---|---|
| ||||
mso:
rainyDay:
retryDurationMultiplier: 2
maxRetries: 5 |
NETCONF Executor in CDS:
The vLB netconf simulator is using NETCONF 1.1, and the CDS Blueprint Processor has a module called Netconf-executor that tries to detect the NETCONF version used when it connects to a NETCONF device. However, the code in NETCONF executor needs to be changed to make the detection work properly.
The needed change is shown here : https://gerrit.onap.org/r/c/ccsdk/cds/+/89900
However, instead of rebuilding CDS Blueprint Processor and creating new docker images, we can find a ready-made CDS Blueprint Processor image here: https://cloud.docker.com/repository/docker/aseaudi/bpp/general
To use this image in our ONAP deployment, we need to modify the default image name of the CDS Blueprint Processor to be image: "aseaudi/bpp:v24" in the deployment.yaml for CDS Blueprint Processor chart in OOM.
We can do this change in several ways, one way is to edit the CDS Blueprint Processor by running "kubectl edit deployment <name of CDS Blueprint Processor deployment>", which will open the deployment for us in a text editor, where we can update the image name, exit and save.
...
SO Orchestration Transition Table Updates:
Code Block |
---|
INSERT INTO `catalogdb`.`orchestration_status_state_transition_directive` (`RESOURCE_TYPE`, `ORCHESTRATION_STATUS`, `TARGET_ACTION`, `FLOW_DIRECTIVE`)
VALUES
('VNF', 'CONFIGURED', 'ACTIVATE', 'CONTINUE'); |
Retry for ConfigDeployVnfBB:
The vLB VM will download source code and will build the netconf simulator that will receive the configuration updates from CDS. This process might take more than 5 minutes.
Due to a default 5 minute timeout value in Camunda BPMN Execution Engine, this means the ConfigDeployVnfBB might fail, which will break the E2E automation of the instantiation.
Thus, we need to tell SO that if ConfigDeployVnfBB fails, it should retry ConfigDeployVnfBB.
We can do this by adding an entry in the SO CATALOG DB rainy_day_handler_macro table, as shown below:
We can do this by connecting to the SO CATALOG DB, and running the following SQL command:
Code Block | ||||
---|---|---|---|---|
| ||||
INSERT INTO rainy_day_handler_macro (FLOW_NAME, SERVICE_TYPE, VNF_TYPE, ERROR_CODE, WORK_STEP, POLICY, SECONDARY_POLICY)
VALUES
('ConfigDeployVnfBB', '*', '*', '*', '*' , 'Retry', 'Abort');
|
Also, in order to allow SO to retry the ConfigDeployVnfBB if it fails the 1st time, we can update the override.yaml file for the SO BPMN INFRA chart in OOM like below:
Code Block | ||||
---|---|---|---|---|
| ||||
mso:
rainyDay:
retryDurationMultiplier: 2
maxRetries: 5 |
Naming Policy:
The override.yaml file above has an option "preload=true", that will tell the POLICY component to run the push_policies.sh script as the POLICY PAP pod starts up, which will in turn create the Naming Policy and push it.
...