Page History

...

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:

https://git.onap.org/sdnc/oam/plain/platform-logic/generic-resource-api/src/main/json/GENERIC-RESOURCE-API_self-serve-unresolved-composite-data.json

https://git.onap.org/sdnc/oam/plain/platform-logic/generic-resource-api/src/main/xml/GENERIC-RESOURCE-API_self-serve-unresolved-composite-data.xml

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.

Image Removed

Image Removed

Image Removed

Image Removed

SO Orchestration Transition Table Updates:

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:

Image Removed

We can do this by connecting to the SO CATALOG DB, and running the following SQL command:

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:

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:

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:

Image Added

We can do this by connecting to the SO CATALOG DB, and running the following SQL command:

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:

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.

...