UPSTREAM: 60978: Fix use of "-w" flag to iptables-restore

[danwinship]

iptables-restore's option-parsing code is weird and broken, and it requires you to say "-w 5" rather than "-w5". Up until now we've never been running OpenShift against a version of iptables new enough to have that flag, so we didn't notice, but 1.6.2 is now in updates-testing in Fedora 27, and when it hits updates, it will totally break kube-proxy in docker-in-docker. (For master/3.9; older releases still use F25 so won't ever see iptables 1.6.2.)

[danwinship]

The iptables update is currently at +3 karma in bodhi (https://bodhi.fedoraproject.org/updates/FEDORA-2018-1c31f1eccd) so it could potentially get pushed to updates at any time. If 3.9 is 100% frozen AND is supposed to be released in the next few days AND the release would be thwarted if extended-networking-minimal failed reliably, then we could consider asking the fedora iptables maintainers to hold the update. Otherwise we should either just get this PR backported quickly, or else revert #18737 on release-3.9 (to put it back to using F25 for dind).

[eparis]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: danwinship, eparis

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• vendor/k8s.io/kubernetes/pkg/util/iptables/OWNERS [eparis]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[danwinship]

Ah, ok, so the reason that we never noticed this is that we backported the code to add "-w" and "-w NUM" to RHEL, but we didn't backport the later patch to make iptables-restore error out when you pass it a bad option (https://git.netfilter.org/iptables/commit/?id=d89dc47). So we're currently running iptables-restore -w5 --noflush --counters, and iptables-restore says "ok, so that's -w, so I'll wait for the lock, and -5, which I don't know what that means, but whatevs, and --noflush, so I won't flush the existing contents, and --counters, so I'll restore counter values. OK!". (So it's actually waiting for the lock forever, not just for 5 seconds.)

So we probably should backport this to 3.7 as well in case RHEL iptables ever gets the error-checking fix. (The bug does not exist in 3.6 and earlier.)

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-merge-robot]

Automatic merge from submit-queue (batch tested with PRs 18908, 18919).

[danwinship]

/cherrypick release-3.9

[openshift-cherrypick-robot]

@danwinship: new pull request created: #18925

In response to this:

/cherrypick release-3.9

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.