action #68851
closedAllow qemu host IP to be something other than 10.0.2.2
Description
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, andtestapi::autoinst_url
uses this address unlessAUTOINST_URL_HOSTNAME
is set, so qemu workers will try to reach the host on http://10.0.2.2 when e.g. uploading assets unlessAUTOINST_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...
Updated by okurz over 4 years ago
- Status changed from New to Feedback
- Assignee set to okurz
Maybe https://github.com/os-autoinst/os-autoinst/pull/1468 can help you.
AdamWill wrote:
[…] 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 havehost_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?
For now I would do it slightly different and live with a tiny duplication in test variables. In the PR I suggest a variable QEMU_HOST_IP
to be able to set the host IP address. The usermode network settings can already be configured with the variable NICTYPE_USER_OPTIONS
. So I suggest to follow https://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29 and set NICTYPE_USER_OPTIONS and QEMU_HOST_IP accordingly.
Updated by okurz over 4 years ago
- Status changed from Feedback to Resolved
https://github.com/os-autoinst/os-autoinst/issues/1468 was merged. We don't plan to use it ourselves. AdamWill will tell me if I messed up :)