Usually the CNI bridge plugin "takes care" of enabling IPv4 forwarding
on all interfaces, see issue #1125, but when the container tests are run
in a different order from the infix_containers.yaml, Infix may reset the
IPv4 forwarding on this critical interface.
This change is both future proof and also ensures the test works as it
was intended even if tests are run out-of-order.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Add test to verify a container on Infix can execute commands on the
host by mounting a script to `/etc/rc.local` with proper permissions.
The test confirms host hostname change using `nsenter` from inside
a privileged container.
Resolves#1024
Libyang is smart, it "fixes" the timezone for you, this was overriden by a
hack in netconf.py and restconf.py, but what you really want is to see
in operational what the current timezone is.
The software list from sysrepo is no longer reversed, the reverse now
happens in cli-pretty. This commit reflects that.
Signed-off-by: Richard Alpe <richard@bit42.se>
{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>
The phys container test verifies custom mounts, so let's refine and
consolidate this test to focus on docker bridge features.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Add new test step that adds a content mount to /var/www/index.html to
verify that changes to a running container are activated.
This test pass was previously part of the container bridge test, but
was moved here to allow that test to focus on bridge specific checks.
Issue #930
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Do not allow the topology matcher to setup a LAG where one link is
running at 10G while the other one runs at 1G, since the bond will
never use the 1G port as long as there the 10G link is up.
To run LAG tests on hardware, we have to make sure that the chosen
links are running at the same speed. We do not want to require a
specific link speed from the logical topology, as the real requirement
is merely that the two (or however many) links are of the _same_
speed, not any _particular_ speed.
Rather than having to complicate the topology matcher, let it take
care of the common pattern of matching requirements to provided
features, then let tests pass custom node/edge matchers for the
complicated cases.