Comment 8 for bug 1612185

Hi Alex,

No, you are not totally right. -n is a WA for the DNS issue. But -w is the preventive action in the future.

Just from your rabbitmq code:

block_client_access()
{
    # do not add temporary RMQ blocking rule, if it is already exist
    # otherwise, try to add a blocking rule with max of 5 retries
    local tries=5
    until $(iptables -wnvL | grep -q 'temporary RMQ block') || [ $tries -eq 0 ]; do
      tries=$((tries-1))
      iptables -w -I INPUT -p tcp -m tcp --dport ${OCF_RESKEY_node_port} -m state --state NEW,RELATED,ESTABLISHED \
      -m comment --comment 'temporary RMQ block' -j REJECT --reject-with tcp-reset
      sleep 1
    done
    if [ $tries -eq 0 ]; then
        return $OCF_ERR_GENERIC
    else
        return $OCF_SUCCESS
    fi

So only this code can block 5 times the xtables from any other services.
And there are a lot of other services like nova-network, ns_hsproxy, ns_vrouter that are also try to access the xtables. And we could not talk about how many times puppet executes iptables command in parallel during the deployment.

Moreover the puppet log says that you should use the -w option.

cic-2.domain.tld/puppet-apply.log:2016-08-09T11:13:25.835603+00:00 err: Execution of '/sbin/iptables -I INPUT 39 -t filter -p tcp -m multiport --ports 10051 -m comment --comment 998 zabbix server vip -j ACCEPT' returned 4: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

So sorry, I strongly disagree with your statement.

BR.
Gergo