Description of problem: Interfaces set up IP address via DHCP and do not honour the configuration done by os-net-config. Version-Release number of selected component (if applicable): os-net-config-5.0.0-0.20161002235507.56c9632.el7ost.noarch openstack-tripleo-heat-templates-5.0.0-0.20161003064637.d636e3a.1.1.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. Dedploy overcloud with network isolation with the following template for controller node: http://paste.openstack.org/show/584794/ 2. On the deployed controller node check the ip address and configuration for nic2 which according to the template should be part of a bridge and have no IP address set Actual results: [root@controller-2 ~]# ip a s dev eth1 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP qlen 1000 link/ether 52:54:00:00:93:18 brd ff:ff:ff:ff:ff:ff inet 172.16.0.91/24 brd 172.16.0.255 scope global dynamic eth1 valid_lft 2298sec preferred_lft 2298sec inet6 fe80::5054:ff:fe00:9318/64 scope link valid_lft forever preferred_lft forever Which doesn't reflect the ifcfg script: cat /etc/sysconfig/network-scripts/ifcfg-eth1 # This file is autogenerated by os-net-config DEVICE=eth1 ONBOOT=yes HOTPLUG=no NM_CONTROLLED=no PEERDNS=no DEVICETYPE=ovs TYPE=OVSPort OVS_BRIDGE=br-isolated BOOTPROTO=none Expected results: The ifcfg scripts are honored and the the setting configured in the nic templates are applied on the deployed nodes. Additional info: There is a dhcp-interface service running which seems to be setting up the DHCP addresses for the NICs: systemctl status dhcp-interface ● dhcp-interface - DHCP interface eth1 Loaded: loaded (/usr/lib/systemd/system/dhcp-interface@.service; disabled; vendor preset: disabled) Active: active (exited) since Fri 2016-10-07 07:50:39 UTC; 2h 10min ago Main PID: 803 (code=exited, status=0/SUCCESS) CGroup: /system.slice/system-dhcp\x2dinterface.slice/dhcp-interface └─1129 /sbin/dhclient -H localhost -1 -q -lf /var/lib/dhclient/dhclient--eth1.lease -pf /var/run/dhclient-eth1.pid eth1 Oct 07 09:59:25 controller-2.localdomain dhclient[1129]: DHCPREQUEST on eth1 to journalctl -l -u dhcp-interface | grep bound Oct 07 08:43:20 controller-2.localdomain dhclient[1129]: bound to 172.16.0.91 -- renewal in 1288 seconds. Oct 07 09:32:47 controller-2.localdomain dhclient[1129]: bound to 172.16.0.91 -- renewal in 1282 seconds.
After running 'systemctl restart network' the network configuration are correctly applied so maybe we are missing a similar step after the scripts in /etc/sysconfig/network-scripts/ get created by os-net-config?
*** Bug 1212532 has been marked as a duplicate of this bug. ***
I have confirmed this bug on bare metal. The dhcp-all-interfaces udev rule does get deleted, but the dhclient process remains running even afterward. I think this is related to RHEL 7.3. I haven't noticed any ill effects from this behavior, were there any side-effects observed from this, or is it mostly cosmetic?
IIRC it also affected the installed routes on the system so the default route was set via DHCP instead of static as defined in the nic template. I'd have to reproduce it on a system to be 100% sure though.
(In reply to Marius Cornea from comment #5) > IIRC it also affected the installed routes on the system so the default > route was set via DHCP instead of static as defined in the nic template. I'd > have to reproduce it on a system to be 100% sure though. Yes, that makes sense. Unfortunately, routes learned through DHCP are favored over static routes. This will require some more investigation and testing.
Upstream patch proposed here - https://review.openstack.org/#/c/396446/.
The upstream patch should address this issue. The patch will add a step to os-net-config after the interfaces and bridges have been brought up, that will check to see if there is a PID file for dhclient on any interfaces that have been configured with static or no IP address. That will remove the dynamic IP and route from the interface.
removing tracker for master
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://rhn.redhat.com/errata/RHEA-2016-2948.html