Bug 1124027 - Set PEERDNS=no in interface configuration files
Summary: Set PEERDNS=no in interface configuration files
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-puppet-modules
Version: 5.0 (RHEL 7)
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ga
: 5.0 (RHEL 7)
Assignee: Gilles Dubreuil
QA Contact: Alexander Chuzhoy
URL:
Whiteboard:
: 1126101 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-28 20:45 UTC by Lars Kellogg-Stedman
Modified: 2014-11-24 02:31 UTC (History)
13 users (show)

Fixed In Version: openstack-puppet-modules-2014.1-19.9.el6ost
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
The vswitch Puppet module provides a new implementation for the vs_port and vs_bridge Puppet resource providers. 1) vs_port When a physical network interface (port) is associated to an Openvswitch bridge, both the bridge and the physical interface need a network configuration file to be created for the configuration to be resilient. For instance, if 'eth0' is attached to 'br-ex', two files, respectively 'ifcfg-br-ex' and 'ifcfg-eth0' will be created in '/etc/sysconfig/network-scripts/' directory. However, in order to addresses various network configuration cases (virtual interface, bonding, vlan, etc.) and therefore potential problems, a new approach was needed. The new implementation still creates the 'ifcfg' file for the port (physical interface) the same way, but it uses the physical interface definitions, if the link is active, to create the 'ifcfg' bridge configuration itself, then it adds the necessary Openvswitch network entries. The vs_port (ovs_redhat) provider includes the following technical changes: - Inheritance from the default provider (OVS) class - A library to handle ifcfg content - Automatic behavior replaces keep_ip and sleep parameters - Puppet-neutron never implemented them so the change is transparent - Requires Puppet 2.7.8+: using commands instead of optional_commands B. vs_bridge The vs_bridge/ovs_redhat.rb has been removed. The puppet resource bridge feature relies on the default OVS provider.
Clone Of:
Environment:
Last Closed: 2014-08-04 18:36:14 UTC
gdubreui: needinfo-
gdubreui: needinfo-

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2014:1003 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform Enhancement Advisory 2014-08-04 22:31:07 UTC
OpenStack gerrit 94504 None None None Never

Description Lars Kellogg-Stedman 2014-07-28 20:45:54 UTC 
During an staypuft deployment, if an system has interfaces other than the provisioning interface using DHCP, *and* the system receives information about dns servers via one of those interfaces, that can overwrite /etc/resolv.conf and cause the deployed host to be unable to resolve the name of the foreman host.

To resolve this, the installer should set PEERDNS=no for all interfaces other than the provisioning interface.
Comment 1 Lars Kellogg-Stedman 2014-07-28 20:47:06 UTC 
This may be a "testing only" problem -- in theory, in a
Real Environment(tm), the foreman server hostname should
be resolvable by any valid dns server...
Comment 3 Alexander Chuzhoy 2014-07-28 23:07:29 UTC 
Happened to me too:
Environment:
rhel-osp-installer-0.1.6-3.el6ost.noarch
openstack-foreman-installer-2.0.16-1.el6ost.noarch
ruby193-rubygem-foreman_openstack_simplify-0.0.6-8.el6ost.noarch
openstack-puppet-modules-2014.1-19.8.el6ost.noarch


used this layout:
https://docs.google.com/drawings/d/14dkoYRNckSv0M3ffXLVbIZtUwrW0rX7wDYkPbyU1YkQ/edit

This causes the deployment to fail, because the host is unable to reach the puppet server (doesn't query the right DNS server).
Comment 4 Lars Kellogg-Stedman 2014-07-29 15:12:12 UTC 
Change proposed in:

https://github.com/larsks/foreman-installer-staypuft/commit/eb8f816b491154e091b35e735a0560eb112ed1a3

Testing it locally right now.
Comment 5 Lars Kellogg-Stedman 2014-07-29 16:32:50 UTC 
Pull request: 

https://github.com/theforeman/foreman-installer-staypuft/pull/56
Comment 8 Lars Kellogg-Stedman 2014-07-29 21:11:06 UTC 
This issue is trickier than we anticipated.  Quoting myself from IRC:

larsks | In the kickstart, we set PEERDNS=no on all the physical interfaces.
larsks | Then for some configurations we add a physical interface to br-ex.
larsks | We do not set PEERDNS=no on br-ex.
     * | hewbrocca facepalm
larsks | If you are using dhcp on br-ex, BOOM, there goes resolv.conf.

So this issue still needs some thought and possibly some documentation.
Comment 9 Lars Kellogg-Stedman 2014-07-29 21:21:06 UTC 
Possible workarounds:

(a) Document "do not use dhcp on external network interfaces"
(b) migrate more of slave device network configuration onto br-ex, including PEERDNS, and things like PEERROUTES, DEFROUTE, etc.
(c) Document workaround for deployer to add to kickstart template.
Comment 10 Hugh Brock 2014-07-29 21:40:41 UTC 
Spoke with Andy Cathrow and this appears to be a blocker.
Comment 11 Lukas Bezdicka 2014-07-30 16:13:51 UTC 
patch 15 should address this
Comment 13 Gilles Dubreuil 2014-08-01 12:33:33 UTC 
patch 15 is broken on static IP cases

patch 16 is now available
Comment 14 Alexander Chuzhoy 2014-08-01 17:26:58 UTC 
Verified:rhel-osp-installer-0.1.6-5.el6ost.noarch


Running "grep PEERDNS /etc/sysconfig/network-scripts/ifcfg-*" on all openstack hosts, I see that this line is set for all the interfaces except the one used to communicate directly with the staypuft itself, which sets the DNS to the staypuft itself - the correct DNS.
Comment 18 Mike Burns 2014-08-04 11:42:01 UTC 
*** Bug 1126101 has been marked as a duplicate of this bug. ***
Comment 19 errata-xmlrpc 2014-08-04 18:36:14 UTC 
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
Comment 20 Gilles Dubreuil 2014-11-24 02:31:36 UTC 
All good!
Note You need to log in before you can comment on or make changes to this bug.