Comment 7 for bug 1712185

Reviewed: https://review.openstack.org/501318
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ae8e37ef6ce254a070d7908fc803baa24e481344
Submitter: Jenkins
Branch: stable/newton

commit ae8e37ef6ce254a070d7908fc803baa24e481344
Author: Ihar Hrachyshka <email address hidden>
Date: Mon Aug 21 12:15:25 2017 -0700

    Make use of -w argument for iptables calls

    Upstream iptables added support for -w ('wait') argument to
    iptables-restore. It makes the command grab a 'xlock' that guarantees
    that no two iptables calls will mess a table if called in parallel.
    [This somewhat resembles what we try to achieve with a file lock we
    grab in iptables manager's _apply_synchronized.]

    If two processes call to iptables-restore or iptables in parallel, the
    second call risks failing, returning error code = 4, and also printing
    the following error:

        Another app is currently holding the xtables lock. Perhaps you want
        to use the -w option?

    If we call to iptables / iptables-restore with -w though, it will wait
    for the xlock release before proceeding, and won't fail.

    Though the feature was added in iptables/master only and is not part of
    an official iptables release, it was already backported to RHEL 7.x
    iptables package, and so we need to adopt to it. At the same time, we
    can't expect any underlying platform to support the argument.

    A solution here is to call iptables-restore with -w when a regular call
    failed. Also, the patch adds -w to all iptables calls, in the iptables
    manager as well as in ipset-cleanup.

    Since we don't want to lock agent in case current xlock owner doesn't
    release it in reasonable time, we limit the time we wait to ~1/3 of
    report_interval, to give the agent some time to recover without
    triggering expensive fullsync.

    In the future, we may be able to get rid of our custom synchronization
    lock that we use in iptables manager. But this will require all
    supported platforms to get the feature in and will take some time.

    Conflicts:
          neutron/agent/linux/iptables_manager.py
          neutron/cmd/ipset_cleanup.py

    Closes-Bug: #1712185
    Change-Id: I94e54935df7c6caa2480eca19e851cb4882c0f8b
    (cherry picked from commit a521bf0393d33d6e69f59900942404c2b5c84d83)