Tests configuration: ip adresses and machines in use

[vankoven]

First idea during tests development was to use 4 distinct machines to run tests:

• one to run HTTP clients,
• one to run HTTP servers,
• one to run Tempesta and
• one to rull them all to run framework itself.

Dividing Tempesta from clients and servers is required in highload testing to eliminate side effects, when multiple CPU intensive tasks are started on one machine. This side effects can lead to very unpredictable load distributions, and scheduler tests can be heavily affected. In the same time we don't want to run Tempesta on the same node where the framework is running: on some development stages Tempesta may crash the kernel and all tests results will be lost. So 4 distinct nodes seemed to be most reliable test bed configuration.

While the tests was developed more and more, it turned out, that there is another type of tests: so called "functional". There is no high load in this tests, but using distinct nodes to run clients and server is very complicated, since framework plays backbone role in the tests. Thus I decided that purely "functional" tests must use two distinct nodes: one for Tempesta and one for framework + client + server. To simplify configuration and in order not to mess it up, client node is not allowed to run remotely and must use the same node as test Framework itself.

Later we discussed the future of the tests (near the time of creation of the new test framework). There were two problems highlighed:

• upcoming fuzzing tests will use TfwBomber which is based on Tempesta code. It runs on kernel level and crashes are possible, so splitting of the framework and client node is required;
• using client node ip address to start Deproxy server looks odd and confusing, so ip property was introduced in General section of tests configuration. But the changes were partly done, most of the functional tests uses Client:ip property, while others - General:ip. Now to properly configure tests, we have to use the same values for Client:ip and General:ip.

To get rid of this misunderstanding we should reformat tests configuration file, to clarify which preset can be used for workload tests and which fore pure functional tests. It must be possible to run heavy loaded clients aside from framework.

[i-rinat]

ip option in section general is not documented at the moment. It's also not mentioned /tests_config.ini.sample, but is actually required.