dts: enforce one DPDK build per test run

Given a pre-built DPDK repository can be supplied to DTS, there is no
need to define multiple build targets. To simplify the process this
change makes each t

dts: enforce one DPDK build per test run

Given a pre-built DPDK repository can be supplied to DTS, there is no
need to define multiple build targets. To simplify the process this
change makes each test run use only one DPDK build whether it's
pre-built or it needs to be built by DTS.

Signed-off-by: Tomáš Ďurovec <tomas.durovec@pantheon.tech>
Signed-off-by: Luca Vizzarro <luca.vizzarro@arm.com>

show more ...

dts: rename build target to DPDK build

Since the DPDK may already be built, some more general name
is needed that includes both the DPDK location and the build
config (if we are going to build).

Si

dts: rename build target to DPDK build

Since the DPDK may already be built, some more general name
is needed that includes both the DPDK location and the build
config (if we are going to build).

Signed-off-by: Tomáš Ďurovec <tomas.durovec@pantheon.tech>
Signed-off-by: Luca Vizzarro <luca.vizzarro@arm.com>

show more ...

dts: rename execution to test run

The configuration containing the combination of:
1. what testbed to use,
2. which tests to run,
3. and what build targets to test

is called an execution. This is c

dts: rename execution to test run

The configuration containing the combination of:
1. what testbed to use,
2. which tests to run,
3. and what build targets to test

is called an execution. This is confusing since we're using the exact
same term to describe other things and execution does not really capture
that well the three items listed above.

A new term is thus needed to describe the configuration. Test run is
much less confusing and better captures what the configuration contains.

Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Reviewed-by: Jeremy Spewock <jspewock@iol.unh.edu>
Reviewed-by: Luca Vizzarro <luca.vizzarro@arm.com>

show more ...

dts: update mypy static checker

Update the mypy static checker to the latest version and fix all the
reported errors.

Bump up supported Poetry shell version.

Bugzilla ID: 1433

Signed-off-by: Luca

dts: update mypy static checker

Update the mypy static checker to the latest version and fix all the
reported errors.

Bump up supported Poetry shell version.

Bugzilla ID: 1433

Signed-off-by: Luca Vizzarro <luca.vizzarro@arm.com>
Reviewed-by: Paul Szczepanek <paul.szczepanek@arm.com>
Reviewed-by: Jeremy Spewock <jspewock@iol.unh.edu>
Reviewed-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Reviewed-by: Nicholas Pratte <npratte@iol.unh.edu>
Tested-by: Nicholas Pratte <npratte@iol.unh.edu>

show more ...

dts: refactor logging configuration

Remove unused parts of the code and add useful features:
1. Add DTS execution stages such as execution and test suite to better
identify where in the DTS lifec

dts: refactor logging configuration

Remove unused parts of the code and add useful features:
1. Add DTS execution stages such as execution and test suite to better
identify where in the DTS lifecycle we are when investigating logs,
2. Logging to separate files in specific stages, which is mainly useful
for having test suite logs in additional separate files.
3. Remove the dependence on the settings module which enhances the
usefulness of the logger module, as it can now be imported in more
modules.

The execution stages and the files to log to are the same for all DTS
loggers. To achieve this, we have one DTS root logger which should be
used for handling stage switching and all other loggers are children of
this DTS root logger. The DTS root logger is the one where we change the
behavior of all loggers (the stage and which files to log to) and the
child loggers just log messages under a different name.

Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Reviewed-by: Jeremy Spewock <jspewock@iol.unh.edu>

show more ...

dts: update docstrings

Format according to the Google format and PEP257, with slight
deviations.

Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>

dts: add node and OS abstractions

The abstraction model in DTS is as follows:
Node, defining and implementing methods common to and the base of SUT
(system under test) Node and TG (traffic generator

dts: add node and OS abstractions

The abstraction model in DTS is as follows:
Node, defining and implementing methods common to and the base of SUT
(system under test) Node and TG (traffic generator) Node.
Remote Session, defining and implementing methods common to any remote
session implementation, such as SSH Session.
OSSession, defining and implementing methods common to any operating
system/distribution, such as Linux.

OSSession uses a derived Remote Session and Node in turn uses a derived
OSSession. This split delegates OS-specific and connection-specific code
to specialized classes designed to handle the differences.

The base classes implement the methods or parts of methods that are
common to all implementations and defines abstract methods that must be
implemented by derived classes.

Part of the abstractions is the DTS test execution skeleton:
execution setup, build setup and then test execution.

Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Tested-by: Bruce Richardson <bruce.richardson@intel.com>
Tested-by: Chenyu Huang <chenyux.huang@intel.com>
Tested-by: Patrick Robb <probb@iol.unh.edu>

show more ...

dts: add basic logging

The logging module provides loggers distinguished by two attributes,
a custom format and a verbosity switch. The loggers log to both console
and more verbosely to files.

Sign

dts: add basic logging

The logging module provides loggers distinguished by two attributes,
a custom format and a verbosity switch. The loggers log to both console
and more verbosely to files.

Signed-off-by: Owen Hilyard <ohilyard@iol.unh.edu>
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>

show more ...