Skip to content

Latest commit

 

History

History
38 lines (25 loc) · 1.99 KB

README.md

File metadata and controls

38 lines (25 loc) · 1.99 KB

trex-operator

Operator behavior

It provides TRex Traffic Generator, decomposed in three components:

  • TRexConfig CR, pinning the config of the TRex server instance. Related pod is trexconfig-<x> pod.
  • TRexApp CR, setting up the job that launches TRex execution to generate traffic towards the system under test. Related pod is trex-app pod.
  • TRex Operator, ensuring CR reconciliation via controller-manager pod. Related pod is trex-operator-controller-manager-<x> pod.

Following information can be extracted from pod logs:

  • In trexconfig-<x> pod logs, you can see the trex statistics printed periodically.
  • The summary of the test execution can be seen at the end of the trex-app job logs.
  • In trex-operator-controller-manager-<x> pod, you can see the execution of the Ansible playbooks that ensures the reconciliation loop of the operator.

How to build the operator

Base structure is achieved with the following commands, then it's just a matter of accommodating the required code for the operator in the corresponding files and folders:

$ mkdir trex-operator; cd trex-operator
$ operator-sdk init --domain openshift.io --plugins ansible
$ operator-sdk create api --version v1 --generate-role --group examplecnf --kind TRexApp
$ operator-sdk create api --version v1 --generate-role --group examplecnf --kind TRexConfig

What to update if bumping operator version

Apart from the modifications you have to do, you also need to update the operator version in these files:

Also, make sure that the operator version is within the interval defined in required-annotations.yaml file for olm.skipRange annotation, else update that file to modify the current range.

A common change is the update of Operator SDK version used in the operator. Here's an example where this is done.