Fuego wiki

Login or create account

Release 1.5 Notes in split format

{{TableOfContents}}
These are the Release Notes for the Fuego 1.5 release, which we are calling "Flame".
These are the Release Notes for the Fuego 1.5 release, which we are calling "Flame".

Major changes [edit section]

run_test * allocate_next_batch_id * Simplified directory layout for the Fuego system * Changed the default port to 8090, from 8080 * New options to install.sh * Ability to specify the TCP port for the Jenkins server * Ability to build a docker container that does not include a Jenkins server * Ability to build a docker container without using the docker image cache * Ability to install Fuego directly to a host machine (not inside a docker container) * Upgraded Fuego base Linux distro to Debian stretch * Upgraded Jenkins version to 2.164.1 * Added many new tests * Added prototype support for sending results to a Squad and fserver back ends * Added new transport: ssh2serial - for ssh to a control board to which the target board is connected by serial port * Added prototype support for board power management via ftc * Fixed output from serio, to support live update of the console log during a command
= Major changes =
The major changes to Fuego in this release are as follows:
 * Added a new "batch test" feature
   * Added ability to manually group tests by batch-id, from the command line
 * Added some new functions to core, for use by test programs:
   * [[function_run_test|run_test]]
   * [[function_allocate_next_batch_id|allocate_next_batch_id]]
 * Simplified directory layout for the Fuego system
 * Changed the default port to 8090, from 8080
 * New options to install.sh
   * Ability to specify the TCP port for the Jenkins server
   * Ability to build a docker container that does not include a Jenkins server
   * Ability to build a docker container without using the docker image cache
 * Ability to install Fuego directly to a host machine (not inside a docker container)
 * Upgraded Fuego base Linux distro to Debian stretch
 * Upgraded Jenkins version to 2.164.1
 * Added many new tests
 * Added prototype support for sending results to a Squad and fserver back ends
 * Added new transport: ssh2serial - for ssh to a control board to which the target board is connected by serial port
 * Added prototype support for board power management via ftc
 * Fixed output from serio, to support live update of the console log during a command

Change details [edit section]

= Change details =

New format for batch tests [edit section]

== New format for batch tests ==
In previous versions of Fuego, testplans were used for running multiple Fuego
tests at the same time.  Fuego 1.5 introduces a new feature called
"batch tests" that implements this functionality, and is intended to replace
the testplan functionality.
See Using Batch Tests for a description of batch tests, and how to use them and write new ones.
See [[Using Batch Tests]] for a description of batch tests, and how
to use them and write new ones.

Ability to manually group tests by batch-id, from the command line [edit section]

Using Batch Tests, which also explains this.)
== Ability to manually group tests by batch-id, from the command line ==
Even if tests are not executed as part of a batch test, it is sometimes 
useful to group multiple tests together.  A user can manually set
the batch-id for a test, by setting an environment variable
FUEGO_BATCH_ID prior to calling 'ftc run-test'.  If you use the same 
batch-id for multiple tests, then you can filter the results by that
batch-id later, to see those test results grouped together in a report.
See the command line help for 'ftc run-test' for information on specifying
a batch_id in a report.  (Or see [[Using Batch Tests]], which also
explains this.)

New test functions [edit section]

run_test * allocate_next_batch_id
== New test functions ==
A few new functions were added to the Fuego test core, for use with
batch tests.  See their respective documentation pages for more
information:
 * [[function_run_test|run_test]]
 * [[function_allocate_next_batch_id|allocate_next_batch_id]]

Simplified directory layout [edit section]

== Simplified directory layout ==
In the Fuego 1.5 release, the directory layout of the Fuego system
was changed.  This was done to simplify the directory structure, and
to reduce some steps required to install Fuego.
Specifically: * fuego-core is now placed inside the top-level 'fuego' directory * the 'engine' directory was removed in fuego-core
Specifically:
 * fuego-core is now placed inside the top-level 'fuego' directory
 * the 'engine' directory was removed in fuego-core
The use of 'engine' in directory paths under fuego-core is now deprecated, and new tests should avoid referencing that directory.
The use of 'engine' in directory paths under fuego-core is now deprecated, and new tests should avoid referencing that directory.
Please note that all tests that come with the Fuego system (ie that are in the fuego-core repository) have already been converted to remove references to the 'engine' directory. However, a symlink was added to the fuego-core directory to support old tests that reference the 'engine' directory.
Please note that all tests that come with the Fuego system (ie that are in the fuego-core repository) have already been converted to remove references to
the 'engine' directory. However, a symlink was added to the fuego-core
directory to support old tests that reference the 'engine' directory.

New default Jenkins server port [edit section]

http://localhost:8090/fuego
== New default Jenkins server port ==
This release changes the default port for the Jenkins server to 8090.
That is, when running with a default installation of Fuego, you should
use the following URL to access the Jenkins server interface:
 * http://localhost:8090/fuego
This was done to make it less likely for Fuego to collide with other networked programs. Specifically, if a machine already has an installation of Jenkins using port 8080, a new, default installation of Fuego will not conflict with this.
This was done to make it less likely for Fuego to collide with other
networked programs.  Specifically, if a machine already has an installation
of Jenkins using port 8080, a new, default installation of Fuego will
not conflict with this.

More install options [edit section]

== More install options =
For a complete list of install.sh options, run ``install.sh --help``

User configurable TCP port [edit section]

=== User configurable TCP port ===
It is now possible to specify the TCP port for Jenkins.  By default the
Fuego uses TCP/IP port 8090, but this can be changed to another port so that
multiple instances of Fuego can be run simultaneously, or to avoid a conflict
with a service already using port 8090 on your host machine.
To use a different port than 8090 for Jenkins, specify it after the image name on the command line when you run install.sh. Note that this means that you must specify a Docker image name in order to specify a non-default port. For example: * install.sh fuego 7777 would install Fuego, with an docker image name of 'fuego', a docker container name of 'fuego-container', and with Jenkins configured to run on port 7777
To use a different port than 8090 for Jenkins, specify it after the
image name on the command line when you run install.sh.  Note that this means
that you must specify a Docker image name in order to specify a non-default
port.  For example:
 * install.sh fuego 7777
would install Fuego, with an docker image name of 'fuego', a docker
container name of 'fuego-container', and with Jenkins configured to run on
port 7777

New --nojenkins option [edit section]

=== New --nojenkins option ===
It is now possible to install Fuego into a docker container that omits
the Jenkins user interface.  Some Fuego users have their own front-ends
and back-ends, and don't need Jenkins.  In Fuego version 1.5, install.sh
now supports an option '--nojenkins' which produces a docker container
to run Fuego without the Jenkins server.  This reduces the overhead
of the docker container by quite a bit, for those users.

New --no-cache option [edit section]

=== New --no-cache option ===
Sometimes, docker image cache data provides stale data for a Fuego 
docker container build.  You can force Fuego to build a container
from a clean slate by specifying the '--no-cache' option on the
install.sh command line.

Ability to install Fuego without a container [edit section]

== Ability to install Fuego without a container ==
Usually, for security and test reproducibility reasons, Fuego is
executed inside a docker container on your host machine.  That is,
by default installing Fuego will create a docker container using
all the software that is needed for Fuego's tests.
However, in some configurations it is desirable to execute Fuego directly on a host machine (not inside a docker container). A user may have a dedicated machine, or they may want to avoid the overhead of running a docker container.
However, in some configurations it is desirable to execute Fuego
directly on a host machine (not inside a docker container).
A user may have a dedicated machine, or they may want to avoid
the overhead of running a docker container.
Several changes were made to support running Fuego (and specifically 'ftc') outside of a docker container. There is a separate install script, called 'install-debian.sh' that is used to install the Fuego system onto a Debian-based Linux distribution.
Several changes were made to support running Fuego (and specifically 'ftc')
outside of a docker container.  There is a separate install script,
called 'install-debian.sh' that is used to install the Fuego system
onto a Debian-based Linux distribution.
Use the script ./install-debian.sh in the top-level fuego directory, instead of ./install.sh, to install Fuego directly into your host machine. Please note that this is not advised unless you know exactly what you are doing. In this configuration, Fuego will likely not be able to manage host-side test dependencies for you correctly.
Use the script ``./install-debian.sh`` in the top-level fuego directory, instead of ``./install.sh``, to install Fuego directly into your host machine.
Please note that this is not advised unless you know exactly what you are
doing.  In this configuration, Fuego will likely not be able to manage
host-side test dependencies for you correctly.
Note that Fuego tests execute bash instruction sequences on the host. So there is a danger when running tests from unknown third parties that they will execute something on your test host that breaches the security.
Note that Fuego tests execute bash instruction sequences on the host.
So there is a danger when running tests from unknown third parties that they will execute something on your test host that breaches the security.  

Upgraded Fuego base Linux distro to Debian stretch [edit section]

== Upgraded Fuego base Linux distro to Debian stretch ==
The Fuego base distribution of Linux (inside the Fuego container) is now
Debian 'Stretch'.  This is an update from Debian Jessie, used in previous
versions of Fuego.
Also, the 'slim' version of the docker image for this distribution is used, in order to save filesystem space (the 'slim' docker image is much smaller than the 'standard' Debian Stretch image).
Also, the 'slim' version of the docker image for this distribution is
used, in order to save filesystem space (the 'slim' docker image is
much smaller than the 'standard' Debian Stretch image).

Upgraded Jenkins version to 2.164.1 [edit section]

== Upgraded Jenkins version to 2.164.1 ==
Fuego now utilizes Jenkins version 2.164.1 for the interface server (front-end
and back-end) of the system.  This more recent version of Jenkins supports
recently updated plugins and security fixes for the system.

Added new Tests [edit section]

== Added new Tests ==
Here is a list of new tests that were added in the v1.5 release:
Distribution functionality tests: * Functional.atmtcp * Functional.brctl * Functional.iperf3_server * Functional.ipmi * Functional.libxml * Functional.module_init_tools * Functional.multipathd * Functional.nscd * Functional.openct * Functional.openhpid * Functional.samba * Functional.vconfig
Distribution functionality tests:
 * Functional.atmtcp
 * Functional.brctl
 * Functional.iperf3_server
 * Functional.ipmi
 * Functional.libxml
 * Functional.module_init_tools
 * Functional.multipathd
 * Functional.nscd
 * Functional.openct
 * Functional.openhpid
 * Functional.samba
 * Functional.vconfig
Fuego self-tests: * Functional.fuego_check_need_module * Functional.fuego_hello_fail_check
Fuego self-tests:
 * Functional.fuego_check_need_module
 * Functional.fuego_hello_fail_check
Tests using other system's tests: * Functional.linaro * Functional.ptest
Tests using other system's tests:
 * Functional.linaro
 * Functional.ptest
Batch tests: * Functional.batch_bc * Functional.batch_default * Functional.batch_fuego_selftest * Functional.batch_hello * Functional.batch_nested_test * Functional.batch_smoketest
Batch tests:
 * Functional.batch_bc
 * Functional.batch_default
 * Functional.batch_fuego_selftest
 * Functional.batch_hello
 * Functional.batch_nested_test
 * Functional.batch_smoketest

Support for results management backends (prototype) [edit section]

== Support for results management backends (prototype) ==
Normally, Fuego results can be examined using one of two methods:
 * the Jenkins web interface
 * the Fuego ftc command line tool
However, this version of Fuego adds prototype support for sending Fuego test results to different results processing backends.
However, this version of Fuego adds prototype support for sending Fuego test results to different results processing backends.
Two that are supported are the "Squad" backend, and the "fserver" backend. For both of these systems, you use the 'ftc put-run' command to transfer results for a run to the backend server.
Two that are supported are the "Squad" backend, and the "fserver" backend.
For both of these systems, you use the 'ftc put-run' command to transfer
results for a run to the backend server.
See the following pages for more information: * Squad backend notes * Using Fuego with fserver
See the following pages for more information:
 * [[Squad backend notes]]
 * [[Using Fuego with fserver]]

NOTE: please note that support for external results management backends is in prototype form. This is not a fully supported Fuego feature yet, and aspects of this feature may change in future releases.

''NOTE: please note that support for external results management backends is
in prototype form.  This is not a fully supported Fuego feature yet, and 
aspects of this feature may change in future releases.''

Added new specialized transport ssh2serial [edit section]

== Added new specialized transport ssh2serial ==
This release of Fuego adds a new specialized transport called 'ssh2serial'.
This transport uses an intermediary computer between the host machine and the target board to
perform operations on the board during a test. The intermediary machine is also referred
to as the "proxy host".
Here is a diagram of the setup: {{{ +--------+ | | ssh +---------------+ +--------------+ | Fuego |<----->| intermediary | serial | board | | host | | machine |<------->| under test | | | | (proxy host) | +--------------+ | | +---------------+ +--------+ }}}
Here is a diagram of the setup:
{{{
  +--------+
  |        |  ssh  +---------------+         +--------------+
  | Fuego  |<----->| intermediary  | serial  |    board     |
  |  host  |       |   machine     |<------->|  under test  |
  |        |       | (proxy host)  |         +--------------+
  |        |       +---------------+
  +--------+
}}}
In order for this to work, you must install 'serio' on the intermediary machine. Also, the intermediary machine needs python (required to run serio tools). Specifically, the commands sercp and sersh should be placed in the directory /usr/local/bin on the intermediary machine.
In order for this to work, you must install 'serio' on the intermediary
machine.  Also, the intermediary machine needs python (required to run
serio tools).  Specifically, the commands ``sercp`` and ``sersh`` should
be placed in the directory /usr/local/bin on the intermediary machine.
Also, you need to provide the following variables to Fuego in the configuration file for the target board (ie fuego-ro/boards/<board>.conf): * TRANSPORT=ssh2serial - indicates to Fuego to use the ssh2serial transport * IPADDR - specifies the address of the proxy host * SSH_PORT (optional) - port for SSH operations on the proxy host (if non-default) * S2S_LOGIN (optional) - account name on proxy host that Fuego can use to connect to it * S2S_PASSWORD (optional) - password on proxy host for Fuego to connect to it * SSH_KEY (optional) - if specified, indicates the key file with authentication tokens for Fuego to use with the proxy host * SERIAL - serial device on proxy host where board is connected * BAUD (optional) - baud rate of serial connection between proxy host and board * LOGIN - account name on board * PASSWORD= (optional) - password of account on the board
Also, you need to provide the following variables to Fuego in the
configuration file for the target board (ie fuego-ro/boards/<board>.conf):
 * TRANSPORT=ssh2serial - indicates to Fuego to use the ssh2serial transport
 * IPADDR - specifies the address of the proxy host
 * SSH_PORT (optional) - port for SSH operations on the proxy host (if non-default)
 * S2S_LOGIN (optional) - account name on proxy host that Fuego can use to connect to it
 * S2S_PASSWORD (optional) - password on proxy host for Fuego to connect to it
 * SSH_KEY (optional) - if specified, indicates the key file with authentication tokens for Fuego to use with the proxy host
 * SERIAL - serial device on proxy host where board is connected
 * BAUD (optional) - baud rate of serial connection between proxy host and board
 * LOGIN -  account name on board
 * PASSWORD= (optional) - password of account on the board
You can either use a LOGIN/PASSWORD combination for access to the proxy host, or use an SSH_KEY file.
You can either use a LOGIN/PASSWORD combination for access to the proxy host, or
use an SSH_KEY file.
A staging area is created under /tmp on the proxy host where files are placed temporarily during transfer to and from the board. There must be sufficient filesystem space available to transfer whatever files any test may require (which may be big, for something like LTP (unless your configuration of LTP uses a pre-installed LTP binaries)).
A staging area is created under /tmp on the proxy host where files are placed
temporarily during transfer to and from the board.  There must be sufficient
filesystem space available to transfer whatever files any test may require
(which may be big, for something like LTP (unless your configuration of LTP uses
a pre-installed LTP binaries)).

Miscelaneous [edit section]

== Miscelaneous ==
 * Fixed output from serio, to support live update of the console log during a command

undocumented changes [edit section]

= undocumented changes =
 * Added a "null.dist" distribution overlay file (for testing non-Linux systems)
 * Refactored the container build scripts
TBWiki engine 1.8.3 by Tim Bird