A new basic_clamp test has been created for Guilin. It is leveraging the python_onapsdk framework.

This test

• creates a service
• includes a TCA blueprint in the design of the service
• onboards the service in SDC
• wait for distribution
• connects clamp, retrieve this service
• instantiates a loop

This test has been created by maezziati

It required

• the development of the clamp part in python-onapsdk: https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk, the clamp schema used for the test is https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk/-/blob/develop/src/onapsdk/clamp/schema_details.json
• the associate pythonsdk-test: https://github.com/onap/testsuite-pythonsdk-tests, the tca microservice is described here https://github.com/onap/testsuite-pythonsdk-tests/blob/master/src/onaptests/configuration/tca-microservice.yaml

The service is properly onboarded and distributed

the test is able to contact clamp, retrieve the policies, check the template and is trying to create a loop.

In the GUI, I can see that the loop is available but not completed.

...

all the logs seen in clamp GUI are attached, as well as the logs of the dcae-gen2 pod (in crashloopbackup) and the logs of policy-api.

dcae-tcagen2 is crashing. I can see java exceptions and errors in policy and dcae logs.

in the attached zip, I put

• logs of the tests: pythonsdk.debug.log
• logs of the dcae-tcagen2 pod
• logs of the policy-api pod
• logs of the clamp GUI when I open the loop

+ vv770d jackl  (DCAE)

sebdet ChrisC (Clamp)

jrh3 pdragosh  (Policy)

MichalJagielloTMPL andreasgeissler jardellos (pythonsdk)

I assign the bug to DCAE first, as I can see the pod in crashloopbackup, but I assume it can be due to a misconfiguration of the tca and/or issue in clamp schema..

any feedback welcome