Previously, periodic iptables calls made by Ironic Inspector did not contain the -w option, which instructs iptables to wait for the xtables lock. As a consequence, periodic iptables updates occasionally failed. This update adds the -w option to the iptables calls, which prevents the periodic iptables updates from failing.
Description of problem:
During hardware introspection, iptables commands are failing because something else is holding the xtables lock. The output of 'journalctl -l -u openstack-ironic-discoverd -f' politely suggests using the -w option:
Oct 09 12:06:48 localhost.localdomain ironic-discoverd[3483]: DEBUG:ironic_discoverd.firewall:Running iptables ('-D', 'INPUT', '-i', 'br-ens4', '-p', 'udp', '--dport', '67', '-j', 'discovery_temp')
Oct 09 12:06:48 localhost.localdomain ironic-discoverd[3483]: DEBUG:ironic_discoverd.firewall:Running iptables ('-A', 'discovery_temp', '-m', 'mac', '--mac-source', u'52:54:00:f5:c6:44', '-j', 'DROP')
Oct 09 12:06:48 localhost.localdomain ironic-discoverd[3483]: DEBUG:ironic_discoverd.firewall:ignoring failed iptables ('-D', 'INPUT', '-i', 'br-ens4', '-p', 'udp', '--dport', '67', '-j', 'discovery_temp'):
Oct 09 12:06:48 localhost.localdomain ironic-discoverd[3483]: iptables: No chain/target/match by that name.
Oct 09 12:06:48 localhost.localdomain ironic-discoverd[3483]: ERROR:ironic_discoverd.firewall:iptables ('-A', 'discovery_temp', '-m', 'mac', '--mac-source', u'52:54:00:f5:c6:44', '-j', 'DROP') failed:
Oct 09 12:06:48 localhost.localdomain ironic-discoverd[3483]: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
The problem is described upstream here: https://bugs.launchpad.net/ironic-inspector/+bug/1484110
The solution in that bug was to add a patch that passes the -w flag to iptables. I believe the same solution applies here.
Version-Release number of selected component (if applicable):
openstack-ironic-discoverd-1.1.0-5.el7ost.noarch
openstack-ironic-api-2015.1.0-9.el7ost.noarch
openstack-ironic-conductor-2015.1.0-9.el7ost.noarch
How reproducible:
For me, every time I've run hardware introspection.
Steps to Reproduce:
1. Run hardware introspection on a bare metal node.
2. Check the output of 'journalctl -l -u openstack-ironic-discoverd -f'
3.
Actual results:
iptables commands fail.
Expected results:
iptables commands wait for the lock to be released.
Additional info:
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-0604.html
Description of problem: During hardware introspection, iptables commands are failing because something else is holding the xtables lock. The output of 'journalctl -l -u openstack-ironic-discoverd -f' politely suggests using the -w option: Oct 09 12:06:48 localhost.localdomain ironic-discoverd[3483]: DEBUG:ironic_discoverd.firewall:Running iptables ('-D', 'INPUT', '-i', 'br-ens4', '-p', 'udp', '--dport', '67', '-j', 'discovery_temp') Oct 09 12:06:48 localhost.localdomain ironic-discoverd[3483]: DEBUG:ironic_discoverd.firewall:Running iptables ('-A', 'discovery_temp', '-m', 'mac', '--mac-source', u'52:54:00:f5:c6:44', '-j', 'DROP') Oct 09 12:06:48 localhost.localdomain ironic-discoverd[3483]: DEBUG:ironic_discoverd.firewall:ignoring failed iptables ('-D', 'INPUT', '-i', 'br-ens4', '-p', 'udp', '--dport', '67', '-j', 'discovery_temp'): Oct 09 12:06:48 localhost.localdomain ironic-discoverd[3483]: iptables: No chain/target/match by that name. Oct 09 12:06:48 localhost.localdomain ironic-discoverd[3483]: ERROR:ironic_discoverd.firewall:iptables ('-A', 'discovery_temp', '-m', 'mac', '--mac-source', u'52:54:00:f5:c6:44', '-j', 'DROP') failed: Oct 09 12:06:48 localhost.localdomain ironic-discoverd[3483]: Another app is currently holding the xtables lock. Perhaps you want to use the -w option? The problem is described upstream here: https://bugs.launchpad.net/ironic-inspector/+bug/1484110 The solution in that bug was to add a patch that passes the -w flag to iptables. I believe the same solution applies here. Version-Release number of selected component (if applicable): openstack-ironic-discoverd-1.1.0-5.el7ost.noarch openstack-ironic-api-2015.1.0-9.el7ost.noarch openstack-ironic-conductor-2015.1.0-9.el7ost.noarch How reproducible: For me, every time I've run hardware introspection. Steps to Reproduce: 1. Run hardware introspection on a bare metal node. 2. Check the output of 'journalctl -l -u openstack-ironic-discoverd -f' 3. Actual results: iptables commands fail. Expected results: iptables commands wait for the lock to be released. Additional info: