*** Kytos End-2-End-Tests***

Overview

The purpose of this repository is to eventually house all the End-to-End code necessary to test the entirety of the Kytos SDN Controller. As of today, the E2E code available analyzes the mef_eline, topology, and maintenance Napps, as well as it ensures the proper start of Kytos without errors. All tests are based on simple Mininet topologies (which are provided in the helpers.py file), and they are executed within a docker container that holds the code for installing all the basic requirements needed to set up an environment capable of executing the tests.

Getting Started

Once you have cloned this project, you need to go into the project repository and run the following command:

$ docker-compose up

This will create and start services as outlined in your docker-compose.yml file, which in this case are to kickstart the installation of the docker images for Kytos and Mininet.

After all installations finish, the docker-compose file will call the kytos-init.sh script which takes care of finishing installing Kytos and all of the required network applications in a quick and efficient way. This script is also responsible for executing all the tests within the projects repository via the commands:

$ python3 -m pytest --timeout=60 tests/

Which runs all available tests, or run only a specific test:

$ python3 -m pytest --timeout=60 \
      tests/test_e2e_10_mef_eline.py::TestE2EMefEline::test_on_primary_path_fail_should_migrate_to_backup

The above lines are entirely up to the user to modify, and will allow them to choose in which way they want to use the tests.

Running Tests Locally

To run tests locally you should create a new venv (Virtual Environment):

$ python3 -m venv venv_name

This venv will have to have current and additional requirements. This can be found within the requirements file and can be done by activating the venv and installing the dependencies with the following commands:

$ source venv_name/bin/activate
$ pip install -r requirements/requirements-local.txt

---

NOTE

You can install dependencies on an existing kytosd environment or use the same one you created both on docker and locally, but other unexpected surprises may arise, such as when you introduce new kytos core dependencies.

For Debian 12 bookworm the packages orphan-sysvinit-scripts and rsyslog need to be installed. The following command will sufice:

$ sudo apt-get update && apt-get install -y orphan-sysvinit-scripts rsyslog

---

You can start running tests locally by adding the mongoLT (Local Test) hosts with the add-etc-local-hosts.sh bash script as follows:

$ ./local_setup/add-etc-local-hosts

Then you can add the required environment variables with the following add-persistent-env-variables.sh bash script:

$ sudo ./local_setup/add-env-variables

Subsequently, the docker-compose.local.yml file can be used with the following command to run all of the required docker containers:

$ docker-compose -f docker-compose.local.yml up -d

To make sure that the DB connectivity is functional run:

$ python scripts/wait_for_mongo.py

Finally, switch to root user as mininet will only run as root and when sudo is used it doesn't have the required dependencies to run kytos and the tests:

$ sudo su -

Make sure to utilize:

$ ./kytos-init.sh

To have the correct settings in order for the tests to run properly!

Logging

Under etc/kytos a file named logging.ini can be found. Logging is a way to track events that occur and view the flow of your program. If you access logging.ini you can view distinct loggers at the end which output information from different parts of the code:

[logger_kytos]
level: DEBUG
qualname: kytos
handlers: syslog,console
propagate=0

You can give these loggers handlers which are the components responsible for deciding where the text generated by the loggers will go. One of the main handlers you should be interested in within the .ini file is the handler_file which outputs the contents of a logger to a specified file:

[handler_file]
class: handlers.RotatingFileHandler
args:["kytos.log", "a", 10*1024*1024, 5]
formatter: file
level: DEBUG

To make use of the handler_file just add "file" in the handlers section under a logger. Next time you run told, a file should be created in the same directory where the logs of the corresponding logger will be outputted. You can then view these logs and use them for troubleshooting. A useful command for this is:

$ tail -f /path/to/file

The tail command usually displays the last few lines of a file, but the -f flag allows the tail command to "follow" the file, and display any new messages added to it within the terminal. This is useful because as kytos runs more logs will be added to the specified file. As you may also notice, there is a "level" section under the handlers and loggers. You can give logs a sort of importance level, which includes values of:

NOTSET=0, DEBUG=10, INFO=20, WARN=30, ERROR=40, and CRITICAL=50

You can set the level to choose which type of information you would like to log based on its importance.

Mininet Topologies

you can run any of those topologies with the following command:

# mn --custom tests/helpers.py --topo ring --controller=remote,ip=127.0.0.1

In the command above _ring is the name of the topology. To see all available topologies:

$ grep "lambda.*Topo" tests/helpers.py

Requirements

• Python
• Mininet
• Docker
• docker-compose
• MongoDB (run via docker-compose)
• Kytos SDN Controller
• kytos/of_core
• kytos/flow_manager
• kytos/topology
• kytos/of_lldp pathfinder
• kytos/mef_eline
• kytos/maintenance