To reduce the duplication of effort between 9pm and the Infamy framework
this change consolidates the move from local 'infamy: title:' extension
to 9pm 'name:'.
For the parameterized tunnel tests we leverage the 9pm dynamic test-spec
variable, which looks for a correspodning <case>.adoc instead of static
Readme.adoc, when generating the test report.
Each test documentation should cover all aspects of the test, much like
the usage text of a UNIX program. To this end, the tunnel test docs are
now more spelled out, including all invariants.
Some refactoring of these tests were also necessary, e.g., replacing any
reserved Python keywords like 'type', and other PEP-8 fixes.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This commit greatly simplifies AsciiDoc image references in generated
Readme.adoc files. The two focused use-cases that remain after this
change are working references in:
- Generated output/images/test-report.pdf
- Viewing test's Readme.adoc from GitHub
Previously we aimed to have working images also when the test's Readme
was included in the parent directory's Readme.adoc. This, however, is
not supported as of this commit. It seems unlikely also to ever be a
supported feature of AsciiDoc on GitHub, for details, see the following
issue: <https://github.com/github/markup/issues/1095>
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
{topdoc} is needed for asciidoctor to find the image during test
report generation.
This is the same functional change as 02d8288863 but with the
generation script actually updated. This was forgotten in the last
commit.
Signed-off-by: Richard Alpe <richard@bit42.se>
Instead of encoding hex data in regular strings, using an 'id:' prefix,
or guessing based on pattern in C code, we have decided for a breaking
change in the DHCP client model.
This commit introduces string and hex values for client-id in the models
for both DHCP client and server. The *breaking* part of the changes are
strictly related to how a user pass binary data as colon-separated hex
digits. The dedicated leaf node `client-id` is now reserved for string
values and the generic `list option` can be used to input user defined
string or hex values. Even non-conformant client-id options can now be
encoded. All described in detail in infix-dhcp-client.yang
The server model has been updated to be able to send generic options in
hex format, and the static host lease matcher for client-id now require
a 'str' or 'hex' modifier.
Note: dnsmasq is RFC compliant and will not match non-conforming option
61 (client-id) even though the client can send such payload.
To increase test coverage, the server_host test has been updated to
check both string and hex client-id. Matching on hostname is already
covered by other test(s).
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
For consistency with the new dhcp-server model, which has an option
value 'name', options are now referred to as id's or identifiers.
This means bumping the confd syntax version 1.3 -> 1.4 and adding a
migration script for existing dhcp-client configuration files.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Implemented logic to check if the system supports required services.
Logical edges with 'requires' fields are mapped only if physical edges
provide corresponding services. If not, the test is skipped.
This ensures that tests only run when the required services are available
in the test system configuration.
Fixes#654
This should be a non functional change. The idea is to use the topdoc
dir from 9pm when generating the test report.
Signed-off-by: Richard Alpe <richard@bit42.se>
SVG is a plain text file, better to see why it changed
than binary PNG. Also fix#744 by adding infix/OEM hash
to test specification
Signed-off-by: Mattias Walström <lazzer@gmail.com>
Now that all routes acquired from DHCP (and ZeroConf) are installed in
the kernel FIB via Frr (staticd -> zebra -> kernel), instead of directly
to the kernel FIB, let's extend this test slightly.
Add a canary static route that is installed before the DHCP client is
even started. This canary route should be installed along with the
DHCP (classless) route(s) when the interface comes up and acquires a
DHCP lease.
We take this opportunity to also verify that the route-preference is
properly carried over from test to operational RIB status.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Joachim Wiberg