New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use iptables-restore xtables lock #1903

Merged
merged 3 commits into from Oct 11, 2018

Conversation

Projects
None yet
2 participants
@fasaxc
Member

fasaxc commented Oct 10, 2018

Description

Based on feature-detection work added in #1901

Todos

Release Note

If deployed with iptables v1.6.2 or above (as included in the calico/felix and calico/node images), all iptables write operations are protected by the xtables global lock.  Previously, the lock was disabled by default but iptables v1.6.2 made the lock mandatory.

@fasaxc fasaxc added the hold-merge label Oct 10, 2018

@fasaxc fasaxc self-assigned this Oct 10, 2018

@fasaxc fasaxc requested a review from projectcalico/core-maintainers as a code owner Oct 10, 2018

Add support for iptables-restore's xtables lock.
- Disable our lock if iptables v1.6.2 is detected.
- Re-use our lock timeout and probe interval config.

@fasaxc fasaxc force-pushed the fasaxc:use-iptables-lock branch 2 times, most recently from f0d8aba to fe7c37b Oct 10, 2018

@fasaxc fasaxc added this to the Calico v3.3.0 milestone Oct 10, 2018

@fasaxc fasaxc force-pushed the fasaxc:use-iptables-lock branch from fe7c37b to 492187b Oct 10, 2018

@fasaxc fasaxc changed the title from [WiP] Use iptables-restore xtables lock to Use iptables-restore xtables lock Oct 10, 2018

@fasaxc fasaxc requested a review from neiljerram Oct 10, 2018

@neiljerram

Looks good. Just 2 or 3 possible nits.

Show resolved Hide resolved iptables/feature_detect.go Outdated
Show resolved Hide resolved iptables/feature_detect.go Outdated
cmd.SetStdin(&inputBuf)
cmd.SetStdout(&outputBuf)
cmd.SetStderr(&errBuf)
countNumRestoreCalls.Inc()
t.writeLock.Lock()
t.calicoXtablesLock.Lock() // Will be a dummy lock if our xtables lock is disabled.

This comment has been minimized.

@neiljerram

neiljerram Oct 10, 2018

Member

I'd prefer "Will be a dummy lock if iptables-restore is acquiring the xtables lock itself."

This comment has been minimized.

@fasaxc

fasaxc Oct 11, 2018

Member

There's more than one reason for it to be disabled but probably worth expanding the comment to explain.

cmd := t.newCmd(t.iptablesRestoreCmd, "--noflush", "--verbose")
args := []string{"--noflush", "--verbose"}
if features.RestoreSupportsLock {
// Versions of iptables-restore that support the xtables lock also make it mandatory. Make sure

This comment has been minimized.

@neiljerram

neiljerram Oct 10, 2018

Member

By "mandatory", do you mean that iptables-restore will give up if the lock is not available immediately? Because it obviously isn't mandatory in the sense that you still need args to tell it to retry...

Mostly just checking my understanding here; I can't think of an obvious wording improvement to the comment.

This comment has been minimized.

@fasaxc

fasaxc Oct 11, 2018

Member

I mean, it won't proceed to do any iptables programming without the lock. Its default behaviour with no args is to quit immediately if it can't acquire the lock.

Will see if I can tighten up the wording.

@fasaxc fasaxc merged commit a192d31 into projectcalico:master Oct 11, 2018

2 checks passed

license/cla Contributor License Agreement is signed.
Details
semaphoreci The build passed on Semaphore.
Details

@fasaxc fasaxc deleted the fasaxc:use-iptables-lock branch Oct 11, 2018

fasaxc added a commit to fasaxc/felix that referenced this pull request Oct 17, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment