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. e.g.: fdi.register_interface=eno2.1000 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 busy 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: vlan=eno2.1000:eno2 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: NoMethodError 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):
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.
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): https://github.com/theforeman/foreman-discovery-image/blob/master/root/usr/bin/nm-prepare I can add a kernel paramter to change DNS and DEFROUTE interface, that should be relatively easy. Filed upstream issue for this: http://projects.theforeman.org/issues/9943 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: http://projects.theforeman.org/issues/9945 I assume you want to have DHCP enabled by default on the VLAN ifaces. Please send additional comments to the upstream issues.
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