Description of problem: Host with multiple active interfaces cannot be assigned to host-group Version-Release number of selected component (if applicable): ruby193-rubygem-staypuft-0.1.0-1.el6ost.noarch foreman-installer-staypuft-0.0.14-1.el6ost.noarch How reproducible: Discover a host with multiple interfaces, assign that host to a host-group. Steps to Reproduce: 1. PXE Boot host 2. Put into host into foreman discover 3. Try to assign that guest to any host-group Actual results: /var/log/foreman-proxy/proxy.log I, [2014-06-09T11:36:34.834827 #23295] INFO -- : Enumerated hosts on 20.0.0.0 D, [2014-06-09T11:36:34.834873 #23295] DEBUG -- : Lazy loaded 20.0.0.0/255.255.255.0 records E, [2014-06-09T11:36:34.835137 #23295] ERROR -- : Record 20.0.0.0/10.16.28.233 not found Expected results: Successful host assign to a host-group Additional info:
Looking a little deeper, this is really foreman discovery functionality. The Host in question comes up with multiple nics (eth0, eth1) getting ip addresses. In this case, eth0 is getting a 10.16 address and eth1 is getting a 20.0.0 address. Staypuft is using 20.0.0 for it's provisioning network. When assigning the role, it seems that Foreman is attempting to apply the 10.16 ip address rather than the 20.0 ip address. Joe, can you post the log from foreman-proxy?
Created attachment 906658 [details] foreman-proxy log
Ohad, any ideas here?
Mike: The Discovery image defaults to eth0, but you can configure Foreman in the Settings menu to use a different fact when importing hosts. Can you try updating it to eth1 and see if it helps?
The discover_bootif is returning with the correct mac address (for em2, which has the 20.0.0.64 address). See below: Fact Value architecture x86_64 discovery_bootif bc:30:5b:f0:41:f5 discovery_version 0.5.4 domain perf.lab.eng.bos.redhat.com facterversion 1.6.6 fqdn pcloud13.perf.lab.eng.bos.redhat.com hardwareisa x86_64 hardwaremodel x86_64 hostname pcloud13 id foreman-proxy interfaces em1,em2,em3,em4,lo,p3p1,p3p2 ipaddress 10.16.29.57 ipaddress_em1 10.16.29.57 ipaddress_em2 20.0.0.64 ipaddress_lo 127.0.0.1 is_virtual false lib /usr/share/ovirt-node-plugin-foreman macaddress BC:30:5B:F0:41:F4 macaddress_em1 BC:30:5B:F0:41:F4 macaddress_em2 BC:30:5B:F0:41:F5 macaddress_em3 BC:30:5B:F0:41:F6 macaddress_em4 BC:30:5B:F0:41:F7 macaddress_p3p1 A0:36:9F:0F:F8:D4 macaddress_p3p2 A0:36:9F:0F:F8:D6 memorysize 126.00 GB memorytotal 126.00 GB netmask 255.255.252.0 netmask_em1 255.255.252.0 netmask_em2 255.255.255.0 netmask_lo 255.0.0.0 network_em1 10.16.28.0 network_em2 20.0.0.0 network_lo 127.0.0.0 processor0 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor1 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor10 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor11 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor12 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor13 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor14 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor15 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor2 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor3 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor4 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor5 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor6 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor7 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor8 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processor9 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz processorcount 16 ps ps -ef selinux false sshdsakey AAAAB3NzaC1kc3MAAACBAJH8hSxRLP3mZ8nm6uS4ZqrEL2eVqnIikrTZ4s9eG9uXv/fxdNsgIf+9be7mKn0ShwCf/L19SPkoR... sshrsakey AAAAB3NzaC1yc2EAAAABIwAAAQEAu8R7Inz3rdH7Uc1un0rgabtfEK6pGPd93OXAfIbNOb9zXOdxle8sJ14IPwaMMPtvVFSlT... uniqueid 100a391d virtual physical
The plugin is probably defaulting to the `ipaddress` when provisioning - normally this is offered to the user to change during the provisioning process (on the 'edi't page after clicking Provision). I assume OFI is using a custom view which doesn't offer this this change to the user?
Workaround: provision a host from 'Discovered Hosts' page. Assign required OpenStack Role (represented by Hostgroup), "discovery" puppet environment, and correct provisioning network. That should equal assigning the host in a Deployment's page. Solution: doesn't need extra fact reported from discovery image. I can pair discovery_bootif with other facts to find the correct network for provisioning. The network will be set automatically on host assignment to OpenStack role.
Ok, Petr once you have the pairing code written, ping me. I will add this into the image so these facts are reported as well. Upsteam: http://projects.theforeman.org/issues/6164
PR: https://github.com/theforeman/staypuft/pull/145
Verified: foreman-installer-staypuft-0.0.18-1.el6ost.noarch Was able to assign a host with 2 active network interfaces and the deployment actually installed the host.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-1003.html