Bug 1108512
| Summary: | Two network interfaces: Could not send facts to Foreman: getaddrinfo: Name or service not known | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Miguel Angel Ajo <majopela> |
| Component: | foreman-discovery-image | Assignee: | Lukas Zapletal <lzap> |
| Status: | CLOSED ERRATA | QA Contact: | Omri Hochman <ohochman> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.0 (RHEL 7) | CC: | aberezin, dnavale, jtaleric, mburns, rhos-maint, sclewis |
| Target Milestone: | ga | ||
| Target Release: | Installer | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://projects.theforeman.org/issues/6268 | ||
| Whiteboard: | |||
| Fixed In Version: | foreman-discovery-image-6.5-20140620.2.el6sat | Doc Type: | Bug Fix |
| Doc Text: |
Previously, when trying to discover a VM with two network interfaces, one in the discovery network, and one in an external network with DHCP and DNS, the VM failsed to send facts to Foreman, and did not get discovered by Foreman Discovery.
With this release, Foreman Discovery image is changed so that DNS is configured for the network interface that is specified by BOOTIF parameter. This is a required parameter and therefore IPAPPEND 2 option must be present in the kernel command line. As a result of this fix, the network interface that is configured from boot using LAN is used to configure DNS.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-08-21 18:04:26 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Miguel Angel Ajo
2014-06-12 07:36:24 UTC
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 |