Bug 1201816 - [RFE] Foreman discovery image should accept a kernel parameter to register over a non-primary NIC or VLAN
Summary: [RFE] Foreman discovery image should accept a kernel parameter to register ov...
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhel-osp-installer
Version: 6.0 (Juno)
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: Installer
Assignee: Mike Burns
QA Contact: Omri Hochman
Depends On:
TreeView+ depends on / blocked
Reported: 2015-03-13 14:56 UTC by Vinny Valdez
Modified: 2017-03-03 17:14 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2016-09-29 13:37:00 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Vinny Valdez 2015-03-13 14:56:39 UTC
Description of problem:
Foreman discovery image currently will attempt to DHCP off the first NIC on the system and attempt to register with Foreman on that network. In a scenario where Foreman is listening on a non-primary, non-native VLAN interface, there should be a parameter such as fdi.register_interface that can be passed to the discovery image. The idea is that it would only bring up that specified interface and register to Foreman over it.



In this scenario Foreman is listening on the VLAN 1000 network.

In the current state with this scenario, the Foreman discovery image fails to boot and stops at a DRACUT prompt with the following errors:

ln: failed to create symbolic link '/run/initramfs/livedev' : File exists
device-mapper: create ioctl on live-rw failed: Device or resource busy
Command failed
device-mapper: create ioctl on live-base failed: Device or resource busy
Command failed
device-mapper: create ioctl on live-osimg-min failed: Device or resource
Command failed
ln: failed to create symbolic link '/dev/root': File exists
Warning: Could not boot

However, adding this parameter allows the image to boot properly:


Unfortunately, though the image boots and the discovery script runs, the primary interface eno1 is brought up and the Foreman server's hostname cannot be resolved and results in errors stating:

Could not send facts to Foreman: getaddrinfo: Name or service not known

bug 1108512 discusses this issue, but since the eno2.1000 interface is not up, setting foreman.url= to the Foreman server doesn't help.

I also tried the following parameters with no luck:

ip=::::eno1:off ip=::::eno2.1001:dhcp

I can manually log into the discovery image, down eno1 and bring up eno2.1000:

ifdown eno1
ip link add link eno2 name eno2.1001 type vlan id 1001
ip link set dev eno2.1001 up
dhclient eno2.1001

Then I need to kill the discovery script and it will restart. The image will now register with Foreman. However, it displays the following error after a few minutes and repeats it over and over:

Response from Foreman 500: { "error": {"message":"address family must be specified"}

In RHEL OSP Installer, when I try to associate this host with a host group, I get the following error:

undefined method `value' for nil:NilClass
app/models/concerns/foreman/thread_session.rb:33:in `clear_thread'
lib/middleware/catch_json_parse_errors.rb:9:in `call'
Version-Release number of selected component (if applicable):

Comment 5 Vinny Valdez 2015-03-13 15:01:41 UTC
FYI I refer to both 1000 and 1001 VLAN IDs in this description. That was an error, they should all be the same VLAN ID.

Comment 6 Lukas Zapletal 2015-03-30 10:56:48 UTC
Vinny, fdi currently configures all ifaces with DHCP (those listed in /sys/class/net/$dev - kernel module must be loaded), only the primary interface is configured to use DNS servers and to be the default route. The code for upstream is here (OSP has slightly older version of this):


I can add a kernel paramter to change DNS and DEFROUTE interface, that should be relatively easy. Filed upstream issue for this:


For the VLAN support, I am not sure if what you are trying to achieve supported scenario. I mean, provisioning on VLAN is perhaps not what we want to target for. The main idea for discovery is to bring unknown hosts, it is not expected to pre-configure things like VLANs for those incoming hosts. You would need to make sure that *all* incoming (unkonwn) hosts are expected to have the very same interface (the same device name). But I understand what your expectations are and filing another feature request upstream for this:


I assume you want to have DHCP enabled by default on the VLAN ifaces.

Please send additional comments to the upstream issues.

Comment 8 Jaromir Coufal 2016-09-29 13:37:00 UTC
Closing list of bugs for RHEL OSP Installer since its support cycle has already ended [0]. If there is some bug closed by mistake, feel free to re-open.

For new deployments, please, use RHOSP director (starting with version 7).

-- Jaromir Coufal
-- Sr. Product Manager
-- Red Hat OpenStack Platform

[0] https://access.redhat.com/support/policy/updates/openstack/platform

Note You need to log in before you can comment on or make changes to this bug.