Description of problem: br-ctlplane interface doesn't come up at boot time after rebooting the undercloud thus some of the containers keep restarting because they cannot bind. Version-Release number of selected component (if applicable): openstack-tripleo-heat-templates-10.2.1-0.20190111152159.64fa74e.fc28.noarch How reproducible: 100% Steps to Reproduce: 1. Install undercloud 2. Reboot undercloud 3. Run 'ip a' to verify the interfaces Actual results: No br-ctlplane interface even though /etc/sysconfig/network-scripts/ifcfg-br-ctlplane is present on the system. Expected results: br-ctlplane interface gets created at boot time. Additional info:
Workaround: bring the interface up manually via ifup br-ctlplane
Marius - did you try installing the rhel network-scripts package on the undercloud? See http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001530.html, in RHEL 8 the support for the ifcfg files in network-scripts now requires the network-scripts package which is not installed by default.
(In reply to Bob Fournier from comment #2) > Marius - did you try installing the rhel network-scripts package on the > undercloud? See > http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001530. > html, in RHEL 8 the support for the ifcfg files in network-scripts now > requires the network-scripts package which is not installed by default. Yes, the network-scripts package was installed manually before the undercloud installation: [stack@undercloud ~]$ dnf info network-scripts Last metadata expiration check: 0:00:13 ago on Wed 16 Jan 2019 02:38:43 PM EST. Installed Packages Name : network-scripts Version : 10.00.1 Release : 1.el8 Arch : x86_64 Size : 172 k Source : initscripts-10.00.1-1.el8.src.rpm Repo : @System From repo : download-node-02.eng.bos.redhat.com_rel-eng_RHEL-8.0-Beta-1.7_compose_BaseOS_x86_64_os_ Summary : Legacy scripts for manipulating of network devices URL : https://github.com/fedora-sysv/initscripts License : GPLv2 Description : This package contains the legacy scripts for activating & deactivating of most : network interfaces. It also provides a legacy version of 'network' service. : : The 'network' service is enabled by default after installation of this package, : and if the network-scripts are installed alongside NetworkManager, then the : ifup/ifdown commands from network-scripts take precedence over the ones provided : by NetworkManager. : : If user has both network-scripts & NetworkManager installed, and wishes to : use ifup/ifdown from NetworkManager primarily, then they has to run command: : $ update-alternatives --config ifup : : Please note that running the command above will also disable the 'network' : service.
I can confirm this behavior. I have a Fedora 29 test box with the following bridge configuration: [dsneddon@localhost network-scripts]$ cat ifcfg-br-ex # This file is autogenerated by os-net-config DEVICE=br-ex ONBOOT=yes HOTPLUG=no NM_CONTROLLED=no PEERDNS=no DEVICETYPE=ovs TYPE=OVSBridge OVS_EXTRA="set bridge br-ex fail_mode=standalone -- del-controller br-ex" BOOTPROTO=static IPADDR=192.168.122.10 NETMASK=255.255.255.0 If I reboot the box, this bridge does not come up, it is listed as "down": 7: br-ex: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 5e:8e:a1:39:71:4b brd ff:ff:ff:ff:ff:ff If I then run "sudo ifup br-ex" the bridge comes up correctly: 7: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 5e:8e:a1:39:71:4b brd ff:ff:ff:ff:ff:ff inet 192.168.122.10/24 brd 192.168.122.255 scope global br-ex valid_lft forever preferred_lft forever inet6 fe80::5c8e:a1ff:fe39:714b/64 scope link valid_lft forever preferred_lft forever So it appears that the ONBOOT=yes is not working correctly with OVS bridges that are not managed by NetworkManager and utilize the network-scripts package instead.
This problem is caused by https://bugzilla.redhat.com/show_bug.cgi?id=1643763 Specifically, the network service is disabled even when the network-scripts package is installed. Running "sudo chkconfig network on" will restore the expected behavior.
new bug has been created - https://bugzilla.redhat.com/show_bug.cgi?id=1667265
*** Bug 1667995 has been marked as a duplicate of this bug. ***
1. Deployed 2. Rebooted undercloud 3. Observe ip a after reboot. br-ctlplane is in the list of networks. However it's state is down and doesn't come UP till you restart the network manually This one is verified, opening another about network down.
For the record, https://bugzilla.redhat.com/show_bug.cgi?id=1701866 is what Sanya reported about the br-ctlplane being down after reboot.
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/RHEA-2019:2811