Project

General

Profile

Actions

action #68851

closed

Allow qemu host IP to be something other than 10.0.2.2

Added by AdamWill over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2020-07-10
Due date:
% Done:

0%

Estimated time:

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, 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...

Actions #1

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 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?

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.

Actions #2

Updated by okurz over 4 years ago

  • Target version set to Ready
Actions #3

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 :)

Actions

Also available in: Atom PDF