Description of problem: When trying to discover a VM with two network interfaces (2 x virtio), one of them in the discovery network, and one of them in an external network with DHCP and DNS, it fails to send facts to Foreman, and it doesn't get discovered. If I remove the external interface (2nd one, as eth1) and reset the VM it will get discovered correctly. Version-Release number of selected component (if applicable): foreman-discovery-image-6.5-20140424.0.1.el6sat.noarch ruby193-rubygem-foreman_discovery-1.3.0-0.1.rc2.el6sat.noarch foreman-installer-1.5.0-0.4.RC2.el6ost.noarch openstack-foreman-installer-2.0.5-1.el6ost.noarch foreman-installer-staypuft-0.0.15-1.el6ost.noarch How reproducible: 100% Steps to Reproduce: 1. Create a VM with 2 network interfaces, 1st one connected to foreman discovery/provisioning network, 2nd one connected to an external network with DHCP and DNS. 2. Boot the VM 3. Actual results: Discovered by URL: https://foreman.rhel6-staypuft.com Registering host with Foreman (https://foreman.rhel6-staypuft.com) Could not send facts to Foreman: getaddrinfo: Name or service not known Expected results: no error Additional info: It seems like it's picking up the 2nd interface DNS servers. It would be interesting to be able to make the DNS server on the first (boot) interface prevail, ignoring any subsequent DNS servers.
A solution for this kind of issues could be setting /etc/hosts with the "foreman discovery host" / IP pair as it's discovered, avoiding this way the need to contact DNS servers to access foreman back.
I suspect that the simple fix for this is to have the default kernel command line use ip address rather than fqdn. That would fail in some circumstances if foreman is providing discovery on multiple networks, but in that case, it would probably be more on the admin to fix that. Lukas, any thoughts on this?
(In reply to Mike Burns from comment #3) > I suspect that the simple fix for this is to have the default kernel command > line use ip address rather than fqdn. That would fail in some circumstances > if foreman is providing discovery on multiple networks, but in that case, it > would probably be more on the admin to fix that. > > Lukas, any thoughts on this? Although, that solution is simpler, and may work in many conditions, it would induce a new failure mode: if foreman is not the default 'website' for the httpd ip address. (Then you go to the http://$ip address, and you get something else but foreman). Under that circumstances it would fail, IMHO, a definitive solution, would be to: include foreman.ip and foreman.host along with foreman.url parameters to the foreman-discovery-image via PXE, And set that as a fixed record in /etc/hosts. Unless we're sure that any foreman deployment is always set as the default website in httpd.
(In reply to Miguel Angel Ajo from comment #4) > (In reply to Mike Burns from comment #3) > Unless we're sure that any foreman deployment is always set as the default > website in httpd. at least for my installation it seems to be, if it's going to be the default setting for an installed foreman, then it could make sense just to use a foreman.url=https://$IP
Ok, I confirmed that setting foreman.url to https://$IP workarounds the problem, just check Comment4 & Comment 3 to see if that's ok. Best, Miguel Ángel.
Guys, the image brings up all interfaces on startup and therefore it takes the DNS settings from DHCP from the last interface. I can acknowledge this is not the best solution and we need to work on it. The question is how we should do this. We apparently need to decide which one to be used. We can use kernel command line for overriding DNS servers perhaps? Or maybe to add all nameservers from all networks (will that work and how to hack this on RHEL6). By the way Foreman supports SRV discovery: https://github.com/theforeman/foreman_discovery#configuration-image which can be used instead of hardcoding the kernel command line.
I like providing it on the kernel command line. It prevents possible issues with multiple foreman instances (production vs test) that have records. I'd suggest either: 1. provide foreman ip address on command line, write /etc/hosts file with ip/fqdn in discovery image 2. use the bootif entry to determine the pxe network and set PEERDNS=no on every *other* network
I like the solution 2 which looks like a sane default. I will add a possibility to override DNS server via kernel commandline too. Created feature ticket: http://projects.theforeman.org/issues/6268 Since we have a workaround, I vote for non-blocker.
If you want help me testing *untested*: http://downloads.theforeman.org/discovery/lzap/peerdns-6268/
I downloaded the image and tried it. It did not work. See comments on the PR https://github.com/theforeman/ovirt-node-plugin-foreman/pull/4
In this build BOOTIF kernel command line option is REQUIRED option. DNS servers from DHCP are taken only for the interface that is specified in the BOOTIF. http://brewweb.devel.redhat.com/brew/taskinfo?taskID=7604937
Verified with ruby193-rubygem-staypuft-0.2.5-1.el6ost.noarch
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/RHBA-2014-1090.html