|
1 | 1 | # CNF Certification Partner |
2 | 2 |
|
3 | 3 | This repository contains two main sections: |
4 | | -* test-partner: A partner pod definition for use on a k8s CNF Certification cluster. |
5 | | -* local-test-infra: A trivial example cluster, primarily intended to be used to run [test-network-function](https://github.com/test-network-function/test-network-function) test suites on a development machine. |
6 | | -This is the basic infrastructure required for "testing the tester". |
7 | | -Also includes a test operator. |
| 4 | +* test-partner: Partner pods definition for use on a k8s CNF Certification cluster. |
| 5 | +* test-target: A trivial example CNF (including a replicaset/deployment, a CRD and an operator), primarily intended to be used to run [test-network-function](https://github.com/test-network-function/test-network-function) test suites on a development machine. |
| 6 | + |
| 7 | +Together, they make up the basic infrastructure required for "testing the tester". |
| 8 | + |
8 | 9 | # Glossary |
9 | 10 |
|
10 | 11 | * Pod Under Test (PUT): The Vendor Pod, usually provided by a CNF Partner. |
@@ -62,13 +63,11 @@ This will create a deployment named "partner" in the "default" namespace. This |
62 | 63 | For disconnected environments, override the default image repo `quay.io/testnetworkfunction` by setting the environment variable named `TNF_PARTNER_REPO` to the local repo. |
63 | 64 | For environments with slow internet connection, override the default deployment timeout value (120s) by setting the environment variable named `TNF_DEPLOYMENT_TIMEOUT`. |
64 | 65 |
|
65 | | -*Note*: Nodes have to be properly labeled (`role=tnfpartner`) for the partner pod to be started. |
66 | | - |
67 | | -# local-test-infra |
| 66 | +# Test-target |
68 | 67 |
|
69 | 68 | Although any CNF Certification results should be generated using a proper CNF Certification cluster, there are times |
70 | | -in which using a local emulator can greatly help with test development. As such, [local-test-infra](./local-test-infra) |
71 | | -provides a very simple PUT, OT, CRD, DP and TPP containing the minimal requirements to perform test cases. |
| 69 | +in which using a local emulator can greatly help with test development. As such, [test-target](./test-target) |
| 70 | +provides a very simple PUT, OT, CRD, which satisfies the minimal requirements to perform test cases. |
72 | 71 | These can be used in conjunction with a local kind or [minikube](https://minikube.sigs.k8s.io/docs/) cluster to perform local test development. |
73 | 72 |
|
74 | 73 |
|
@@ -103,7 +102,7 @@ Or Alternatively, run: |
103 | 102 | make rebuild-minikube |
104 | 103 | ``` |
105 | 104 |
|
106 | | -## Start local-test-infra |
| 105 | +## Deploy both test target and test partner as a local-test-infra |
107 | 106 |
|
108 | 107 | To create the resources, issue the following command: |
109 | 108 |
|
@@ -144,9 +143,9 @@ You should see something like this (note that the 2 test pods are running on dif |
144 | 143 | NAME NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES |
145 | 144 | tnfpartner-678db9858c-f9p4f 1/1 Running 0 142m 10.244.4.2 minikube-m05 <none> <none> |
146 | 145 | ``` |
147 | | -## Stop local-test-infra |
| 146 | +## Delete local-test-infra |
148 | 147 |
|
149 | | -To tear down the local test cluster use the following command. It may take some time to completely stop the PUT, CRD, OT, DP and TPP: |
| 148 | +To tear down the local test infrastruture from the cluster, use the following command. It may take some time to completely stop the PUT, CRD, OT, DP and TPP: |
150 | 149 |
|
151 | 150 | ```shell-script |
152 | 151 | make clean |
|
0 commit comments