Bug 1334895
| Summary: | dnsmasq dispatcher script doesn't work for static interfaces | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Scott Dodson <sdodson> |
| Component: | Installer | Assignee: | Scott Dodson <sdodson> |
| Status: | CLOSED ERRATA | QA Contact: | Ma xiaoqiang <xiama> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.2.0 | CC: | aos-bugs, erich, gcarmin, jokerman, jswensso, mmccomas, plarsen, sdodson, xtian |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | openshift-ansible-3.0.90-1.git.0.a077b68.el7 | Doc Type: | Bug Fix |
| Doc Text: |
The NetworkManager dispatcher script which configures dnsmasq in OpenShift 3.2 did not account for static network configurations. The dispatcher script has been updated to work for static network configurations.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-06-07 10:56:08 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
Scott Dodson
2016-05-10 18:25:58 UTC
Did this go into GA yet? (did a 3.2GA install and had the same problem) No, not yet. This will be in the first post 3.2 update coming soon. (In reply to Scott Dodson from comment #3) > No, not yet. This will be in the first post 3.2 update coming soon. Thanks Scott. I guess we need to post a work-around KSC in the mean time? I'll leave that up to support to decide what to do. I don't believe that many users will use staticly configured interfaces but I may be wrong. Please collaborate with support if you want a solution written up. (In reply to Scott Dodson from comment #5) > I'll leave that up to support to decide what to do. I don't believe that > many users will use staticly configured interfaces but I may be wrong. > Please collaborate with support if you want a solution written up. I was under the impression that statically defined interfaces were a requirement for OpenShift to function and work properly, as changing IP addresses via DHCP leases can lead to outages or miss-configurations on the openshift configuration side, especially if these changes don't propagate to DNS. Scott with out the code from the PR what is the defined workaround to this issue? If we have a solutions we can document it into a KCS solution. You can add the host's defined DNS servers to /etc/dnsmasq.d/static-workaround.conf in the following format and restart dnsmasq. server=4.4.4.4 server=8.8.8.8 I really do suspect almost no one is using static configurations though. (In reply to Scott Dodson from comment #7) > You can add the host's defined DNS servers to > /etc/dnsmasq.d/static-workaround.conf in the following format and restart > dnsmasq. > > server=4.4.4.4 > server=8.8.8.8 > > I really do suspect almost no one is using static configurations though. I'll like to add to this bugzilla that I know of NO installation that does NOT use static IPs (not using DHCP). Not even on a cloud service solution like AWS. I understand that some deployment automation tools (like our Satellite and OpenStack) works from the presumption that it controls the DHCP setup and can add static entries for the MACs when provisioning new servers. That's not the typical use-case I've seen with OSE for now - in particular in pre-production (evaluation) environments. I have created a solution for this issue to mitigate the short term effects of this bug. Check on openshift-ansible-3.0.90-1 Install env with static IP #vim /etc/sysconfig/network-script/ifcfg-eth0 BOOTPROTO="static" IPADDR=192.168.2.226 GATEWAY=192.168.2.2 TYPE=Ethernet DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no PEERDNS=yes PEERROUTES=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes DNS1=10.73.2.107 DNS2=10.73.2.108 DNS3=192.168.2.2 after installation, check the resolv.conf # cat /etc/resolv.conf # Generated by NetworkManager search lab.eng.nay.redhat.com nameserver 192.168.2.226 nameserver 192.168.2.226 nameserver 192.168.2.226 # nameserver updated by /etc/NetworkManager/dispatcher.d/99-origin-dns.sh Get the expected result, move this issue to VERIFIED 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. https://access.redhat.com/errata/RHBA-2016:1208 |