CNF Certification Partner

This repository contains two main sections:

test-partner: A partner pod definition for use on a k8s CNF Certification cluster.
local-test-infra: A trivial example cluster, primarily intended to be used to run test-network-function test suites on a development machine. This is the basic infrastructure required for "testing the tester". Also includes a test operator.

Glossary

Pod Under Test (PUT): The Vendor Pod, usually provided by a CNF Partner.
Operator Under Test (OT): The Vendor Operator, usually provided by a CNF Partner.
Test Partner Pod (TPP): A Universal Base Image (UBI) Pod containing the test tools and dependencies to act as a traffic workload generator or receiver. For generic cases, this currently includes ICMPv4 only.
Debug Pod (DP): A Pod running RHEL support tool image deployed as part of a daemon set for accessing node information. DPs is deployed in "default" namespace
CRD Under Test (CRD): A basic CustomResourceDefinition.

Namespace

By default, TPP and DP are deployed in "default" namespace. all the other deployment files in this repository use tnf as default namespace. A specific namespace can be configured using:

export TNF_EXAMPLE_CNF_NAMESPACE="tnf" #tnf for example

Test-partner

test-partner provides the basic configuration to create a CNF Test Partner Pod (TPP), which is used to verify proper operation of a Partner Vendor's Pod Under Test in a CNF Certification Cluster. The Pod is composed of a single container, which is based off Universal Base Image (UBI) 8. A minimal set of tools is installed on top of the base image to fulfill CNF Test dependency requirements:

iputils (for ping)
iproute (for ip)

If you are using a different test partner pod, please ensure you provide these or the image will be unable to run all CNF Certification tests.

Cloning the repository

The repository can be cloned to local machine using:

git clone git@github.com:test-network-function/cnf-certification-test-partner.git

(Re)Building the container image

In order to build the test-partner image, the code should be cloned locally. The following command should be issued:

docker build --no-cache -f Dockerfile -t testnetworkfunction/cnf-test-partner .

If needed (and authorized) the following will update the stored image:

docker push testnetworkfunction/cnf-test-partner

Installing the partner pod

In order to create and deploy the partner pod, use the following:

make install-partner-pods

This will create a deployment named "partner" in the "default" namespace. This Pod is the test partner for running CNF tests. For disconnected environments, override the default image repo quay.io/testnetworkfunction by setting the environment variable named TNF_PARTNER_REPO to the local repo. For environments with slow internet connection, override the default deployment timeout value (120s) by setting the environment variable named TNF_DEPLOYMENT_TIMEOUT.

Note: Nodes have to be properly labeled (role=tnfpartner) for the partner pod to be started.

local-test-infra

Although any CNF Certification results should be generated using a proper CNF Certification cluster, there are times in which using a local emulator can greatly help with test development. As such, local-test-infra provides a very simple PUT, OT, CRD, DP and TPP containing the minimal requirements to perform test cases. These can be used in conjunction with a local kind or minikube cluster to perform local test development.

Dependencies

In order to run the local test setup, the following dependencies are needed:

minikube
VirtualBox (or another driver for minikube)
oc client
kubectl

Setup

To start minikube, issue the following command:

minikube start --embed-certs --driver="virtualbox" --nodes 3

The --embed-certs flag will cause minikube to embed certificates directly in its kubeconfig file.
This will allow the minikube cluster to be reached directly from the container without the need of binding additional volumes for certificates.

The --nodes 3 flag creates a cluster with one master node and two worker nodes. This is to support anti-affinity and pod-recreation test case.

To avoid having to specify this flag, set the embed-certs configuration key:

minikube config set embed-certs true

Or Alternatively, run:

make rebuild-minikube

Start local-test-infra

To create the resources, issue the following command:

make install

This will create a PUT named "test" in TNF_EXAMPLE_CNF_NAMESPACE namespace, TPP named "tnfpartner" which can be used to run test suites, and Debug Daemonset named "debug". The example tnf_config.yml in test-network-function will use this local infrastructure by default.

Note that this command also creates OT and CRD resources.

To verify test pods are running:

oc get pods -n $TNF_EXAMPLE_CNF_NAMESPACE -o wide

You should see something like this (note that the 2 test pods are running on different nodes due to a anti-affinity rule):

NAME                                                              READY   STATUS      RESTARTS   AGE     IP           NODE           NOMINATED NODE   READINESS GATES
4c926df73b15df26b6874260a4f71ca3bf7c6ce2bdfd87aa90759a6aeb5rhpk   0/1     Completed   0          59s     10.244.0.5   minikube       <none>           <none>
nginx-operator-controller-manager-7f8f449fbd-fvn4f                2/2     Running     0          44s     10.244.0.6   minikube       <none>           <none>
quay-io-testnetworkfunction-nginx-operator-bundle-v0-0-1          1/1     Running     0          69s     10.244.2.6   minikube-m03   <none>           <none>
test-697ff58f87-88245                                             1/1     Running     0          2m20s   10.244.2.2   minikube-m03   <none>           <none>
test-697ff58f87-mfmpv                                             1/1     Running     0          2m20s   10.244.1.3   minikube-m02   <none>           <none>

To verify partner pod is running:

oc get pods -n default -o wide