I am deploying a non-HA configuration and having staypuft configure external network connectivity. During the initial puppet run when the system boots, br-ex is getting partially configured, but left with an address. This leaves the system without any network connectivity, since I have configured staypuft to use eth0 (aka the provisioning interface) for external access. This is the log from puppet: Jul 25 19:33:12 mac52540036b16c.localdomain puppet-agent[1959]: (/Stage[main]/Neutron::Agents::Ovs/Neutron_plugin_ovs[OVS/bridge_mappi ngs]/ensure) created Jul 25 19:33:12 mac52540036b16c.localdomain ovs-vsctl[11004]: ovs|00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl add-br br-ex Jul 25 19:33:12 mac52540036b16c.localdomain puppet-agent[1959]: (/Stage[main]/Neutron::Agents::Ovs/Neutron::Plugins::Ovs::Bridge[physnet-external:br-ex]/Vs_bridge[br-ex]/ensure) created Jul 25 19:33:13 mac52540036b16c.localdomain ovs-vsctl[11021]: ovs|00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl add-port br-ex eth0 Jul 25 19:33:14 mac52540036b16c.localdomain systemd[1]: Stopping Puppet agent... Jul 25 19:33:14 mac52540036b16c.localdomain puppet-agent[1755]: Caught TERM; calling stop Jul 25 19:33:14 mac52540036b16c.localdomain puppet-agent[1959]: Caught TERM; calling stop Jul 25 19:33:14 mac52540036b16c.localdomain systemd[1]: Starting Puppet agent... Jul 25 19:33:14 mac52540036b16c.localdomain systemd[1]: Started Puppet agent. Jul 25 19:33:16 mac52540036b16c.localdomain puppet-agent[11059]: Starting Puppet client version 3.6.2 Jul 25 19:33:17 mac52540036b16c.localdomain puppet-agent[11069]: Unable to fetch my node definition, but the agent run will continue: As you can see, puppet-agent stops immediately after the call to 'add-port br-ex eth0'. Looking at the system logs implicates NetworkManager: Jul 25 19:33:14 mac52540036b16c.localdomain NetworkManager[632]: <info> (eth0): deactivating device (reason 'connection-removed') [38] Jul 25 19:33:14 mac52540036b16c.localdomain dbus[526]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' Jul 25 19:33:14 mac52540036b16c.localdomain dbus-daemon[526]: dbus[526]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' Jul 25 19:33:14 mac52540036b16c.localdomain systemd[1]: Starting Network Manager Script Dispatcher Service... Jul 25 19:33:14 mac52540036b16c.localdomain NetworkManager[632]: <info> (eth0): canceled DHCP transaction, DHCP client pid 1373 Jul 25 19:33:14 mac52540036b16c.localdomain dbus-daemon[526]: dbus[526]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Jul 25 19:33:14 mac52540036b16c.localdomain dbus[526]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher' Jul 25 19:33:14 mac52540036b16c.localdomain systemd[1]: Started Network Manager Script Dispatcher Service. Jul 25 19:33:14 mac52540036b16c.localdomain systemd[1]: Stopping Puppet agent... Jul 25 19:33:14 mac52540036b16c.localdomain puppet-agent[1755]: Caught TERM; calling stop Jul 25 19:33:14 mac52540036b16c.localdomain puppet-agent[1959]: Caught TERM; calling stop Here you can see that NM starts the dispatcher service to handle the disconnect event for eth0, and immediately puppet-agent gets killed.
And with NetworkManager disabled, br-ex gets configured correctly and the deploy continues successfully: Jul 25 20:16:24 mac52540036b16c.localdomain ovs-vsctl[11132]: ovs|00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl add-br br-ex Jul 25 20:16:24 mac52540036b16c.localdomain kernel: device br-ex entered promiscuous mode Jul 25 20:16:24 mac52540036b16c.localdomain puppet-agent[1969]: (/Stage[main]/Neutron::Agents::Ovs/Neutron::Plugins::Ovs::Bridge[physnet-external:br-ex]/Vs_bridge[br-ex]/ensure) created Jul 25 20:16:25 mac52540036b16c.localdomain ovs-vsctl[11149]: ovs|00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl add-port br-ex eth0 Jul 25 20:16:25 mac52540036b16c.localdomain kernel: device eth0 entered promiscuous mode Jul 25 20:16:26 mac52540036b16c.localdomain ovs-vsctl[11244]: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --if-exists del-port br-ex eth0 Jul 25 20:16:26 mac52540036b16c.localdomain kernel: device eth0 left promiscuous mode Jul 25 20:16:27 mac52540036b16c.localdomain ovs-vsctl[11300]: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --if-exists del-br br-ex Jul 25 20:16:27 mac52540036b16c.localdomain kernel: device br-ex left promiscuous mode Jul 25 20:16:27 mac52540036b16c.localdomain ovs-vsctl[11334]: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --may-exist add-br br-ex -- set bridge br-ex other-config:hwaddr=52:54:00:36:b1:6c Jul 25 20:16:27 mac52540036b16c.localdomain kernel: device br-ex entered promiscuous mode Jul 25 20:16:28 mac52540036b16c.localdomain ovs-vsctl[11394]: ovs|00001|vsctl|INFO|Called as ovs-vsctl -t 10 -- --may-exist add-port br-ex eth0 Jul 25 20:16:28 mac52540036b16c.localdomain kernel: device eth0 entered promiscuous mode Jul 25 20:16:28 mac52540036b16c.localdomain dhclient[11419]: DHCPDISCOVER on br-ex to 255.255.255.255 port 67 interval 3 (xid=0x40c1bfaf) Jul 25 20:16:28 mac52540036b16c.localdomain dhclient[11419]: DHCPREQUEST on br-ex to 255.255.255.255 port 67 (xid=0x40c1bfaf) Jul 25 20:16:28 mac52540036b16c.localdomain dhclient[11419]: DHCPOFFER from 172.16.0.1 Jul 25 20:16:28 mac52540036b16c.localdomain dhclient[11419]: DHCPACK from 172.16.0.1 (xid=0x40c1bfaf) Jul 25 20:16:30 mac52540036b16c.localdomain NET[11464]: /usr/sbin/dhclient-script : updated /etc/resolv.conf Jul 25 20:16:30 mac52540036b16c.localdomain dhclient[11419]: bound to 172.16.0.6 -- renewal in 296 seconds.
https://github.com/theforeman/foreman-installer-staypuft/pull/55
NetworkManager is down as expected. ruby193-rubygem-staypuft-0.1.22.el6ost
This bug is only relevant when you use the same NIC for both provisioning and external access, correct? Also, with NM off, before the puppet run, eth0 has an IP address, and when the run finishes that IP is on br-ex? This is not the case with NM on? If you would run with NM on and SSH into the machine on a different NIC, would br-ex end up with an IP or not?
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/RHBA-2014-1090.html