QA (public) » openQA Project (public)

os-autoinst currently has some pretty strong assumptions about the IP address 10.0.2.2:

• testapi::host_ip is always 10.0.2.2 for qemu instances, and testapi::autoinst_url uses this address unless AUTOINST_URL_HOSTNAME is set, so qemu workers will try to reach the host on http://10.0.2.2 when e.g. uploading assets unless AUTOINST_URL_HOSTNAME is set
• For non-tap workers, this is the default IP for the host in usermode networking
• For tap workers, the bridge interface on the worker host must have the IP 10.0.2.2/15. This is enforced in os-autoinst-openvswitch

I got a request from Fedora infra folks asking if our openQA instance can stop using 10.0.2.2 (I'm not yet sure if the br0 interface is the only problem, or if jobs that use usermode networking are also an issue), so I started work on a patch to allow us to use 172.16.2.2 instead, but it seems not really super straightforward, so I'm filing an issue to see if other folks have thoughts on how to handle this.

It's relatively easy to conditionalize the stuff in os-autoinst-openvswitch a bit to allow for the bridge to be at either 10.0.2.2/15 or 172.16.2.2/15 and adjust the rules depending on which it is. But it's testapi::host_ip and the usermode networking case that I'm kind of struggling with the best way to handle. Should we have a new variable that causes us to run qemu with params to use 172.16.2.2 instead of 10.0.2.2 if we're doing usermode networking, and have host_ip look at that variable too, and trust the sysadmin will use 172.16.2.2 for the bridge if they're setting that variable? Can anyone think of anything better? Is anyone aware of anything I'm missing here?

Another option I have is to just write a downstream patch which straight swaps out all the 10.0.2.2 assumptions for 172.16.2.2 assumptions and just use that for our deployment, but then I get to maintain that forever, and someone might add a new thing upstream that assumes 10.0.2.2 and break our stuff until I notice it...