Context

In Istambul we would like to cleanup the way we are launching our CI/CD tests.

There are 2 main ways to launch the tests:

• as a docker out of ONAP cluster

• as a k8s job: for the moment it was run inside the onap namespace but it is possible to execute the test in a dedicated testing namespace

Historical robotframework based tests are executed either manually through e2e scripts calling the robot pods or thanks to k8s job run in CI (leveraging the same code than the one in robot)

How to move from internal to external namespace?

Usually the k8s pod requires the inputs from the robot configmap

Assuming that

• we create a new namespace e.g onap-testing

• we create a configmap (same than the robot configmap in the onap ns) in this new name space (or we grant access to the existing one but ultimately it would be good to move also robot pod out of onap namespace)

several tests works well out of the box in onap-testing context

• core

• full

• postinstall

• healthdist

• ves-collector

Some may need some adaptations, the main issues can be

• hosts mentioned in the tests are not resolvable: it is possible to contact a host on another namespace but the namespace must be specified e.g. dcaemod-runtime-api.onap could be called from onap-testing namespcae, dcaemod-runtime-api will fail so the url needs be include the onap namesapce on the test side

• your test is calling kubernetes command directly on the onap namespace: concretely you are performing a kubectl get pod -n onap  or kubectl cp wheteverpod:/whateverfile . -n onap. In this case rights must be granted to onap-xtesting (Role/rbac) to allow you to call onap resources from onap-testing namespace

Work in Progress