openQA tests and tool change: use 172.16 / 172.17 IP range instead of 10.0 / 10.1

[Adam Williamson]

Hey folks!

Wanted to give folks with their own deployments of the Fedora openQA
tests and tools a heads-up: I'm currently pushing out a set of changes
which makes them use the IP ranges 172.16.x.x and 172.17.x.x instead of
10.0.x.x and 10.1.x.x. This will require you to change a few things on
your deployments.

You'll need to update os-autoinst to version
os-autoinst-4.6-20.20200623git5038d8c.fc32 or higher:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-b57c29f71c

You'll need to update fedora_openqa (and install it systemwide if you
use a systemwide installation of it) and os-autoinst-distri-fedora and
reload templates with fifloader. On all tap worker hosts you have, you
also need to edit /etc/sysconfig/ifcfg-br0 and change the IP from
10.0.2.2 to 172.16.2.2, and create a file /etc/sysconfig/os-autoinst-
openvswitch with this content:

OS_AUTOINST_BRIDGE_LOCAL_IP=172.16.2.2
OS_AUTOINST_BRIDGE_REWRITE_TARGET=172.17.0.0

Then it's probably best to restart the tap worker host(s). You don't
need to restart the server, just restart the job scheduler messaging
consumer if you use it.

I could make this configurable, but it's a bit awkward and I hope the
changes shouldn't be too much work for folks. I'm going to update the
relevant documentation to explain this too. Please yell if this causes
you too much trouble or if it doesn't seem to be working, and I'll see
what I can do.

For a bit of technical background - until recently the use of 10.0.2.2
as the qemu host IP and the expectation that tap workers would use an
IP in the 10.0.2 range (there is some complex openvswitch magic in os-
autoinst-openvswitch which then rewrites that traffic into the 10.1.x
range to avoid collisions between multiple instances of identical tests
running simultaneously) was hardcoded into os-autoinst. However, the
Fedora infra folks let me know that using the 10.0 range was a problem
because the infra network itself is in that range, and they're seeing
network issues they think are related to the use of 10.0.2.2. So I
worked with okurz from upstream on a patch:
https://github.com/os-autoinst/os-autoinst/pull/1468
that makes this configurable at the os-autoinst level.