Bug 1382653 - Interfaces configure IP address via DHCP and do not honour the configuration done by os-net-config
Summary: Interfaces configure IP address via DHCP and do not honour the configuration ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: os-net-config
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: rc
: 10.0 (Newton)
Assignee: Dan Sneddon
QA Contact: Omri Hochman
URL:
Whiteboard:
: 1212532 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-07 10:06 UTC by Marius Cornea
Modified: 2016-12-14 16:12 UTC (History)
20 users (show)

Fixed In Version: os-net-config-5.0.0-5.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-14 16:12:38 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:2948 normal SHIPPED_LIVE Red Hat OpenStack Platform 10 enhancement update 2016-12-14 19:55:27 UTC
OpenStack gerrit 398498 None None None 2016-11-18 14:44:17 UTC
Launchpad 1640598 None None None 2016-11-11 11:22:38 UTC

Internal Links: 1212532

Description Marius Cornea 2016-10-07 10:06:30 UTC
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@eth1.service service running which seems to be setting up the DHCP addresses for the NICs:

systemctl status dhcp-interface@eth1.servicedhcp-interface@eth1.service - 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@eth1.service
           └─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@eth1.service | 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.

Comment 1 Marius Cornea 2016-10-07 10:09:42 UTC
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?

Comment 3 Dmitry Tantsur 2016-10-20 11:53:00 UTC
*** Bug 1212532 has been marked as a duplicate of this bug. ***

Comment 4 Dan Sneddon 2016-10-21 19:14:14 UTC
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?

Comment 5 Marius Cornea 2016-10-21 19:41:17 UTC
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.

Comment 6 Dan Sneddon 2016-10-21 20:12:07 UTC
(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.

Comment 10 Bob Fournier 2016-11-11 03:07:29 UTC
Upstream patch proposed here - https://review.openstack.org/#/c/396446/.

Comment 11 Dan Sneddon 2016-11-11 11:35:22 UTC
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.

Comment 18 Jon Schlueter 2016-11-18 14:52:35 UTC
removing tracker for master

Comment 22 errata-xmlrpc 2016-12-14 16:12:38 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.

https://rhn.redhat.com/errata/RHEA-2016-2948.html


Note You need to log in before you can comment on or make changes to this bug.