k8snetworkplumbingwg / multus-cni / 6175935444

65%

master: 56%

Build Type

Pull #1154

github

Committed by dcbw

Commit Message

server: don't set CNI config readinessindicatorfile when using ConfigManager

For whatever reason calling os.Stat() on the readiness indicator file
from CmdAdd()/CmdDel() when multus is running in server mode and is
containerized often returns "file not found", which triggers the
polling behavior of GetReadinessIndicatorFile(). This greatly delays
CNI operations that should be pretty quick. Even if an exponential
backoff is used, os.Stat() can still return "file not found"
multiple times, even though the file clearly exists.

But it turns out we don't need to check the readiness file in server
mode when running with MultusConfigFile == "auto". In this mode the
server starts the ConfigManager which (a) waits until the file exists
and (b) fsnotify watches the readiness and (c) exits the daemon
immediately if the file is deleted or moved.

This means we can assume that while the daemon is running and the
server is handling CNI requests that the readiness file exists;
otherwise the daemon would have exited. Thus CmdAdd/CmdDel don't
need to run a lot of possibly failing os.Stat() calls in the CNI
hot paths.

Signed-off-by: Dan Williams <dcbw@redhat.com>

Pull Request Pull Request #1154: [wip] Performance and efficiency improvements in daemon/server mode

Run Details

148 of 210 new or added lines in 5 files covered. (70.48%)

3 existing lines in 3 files now uncovered.

2255 of 3481 relevant lines covered (64.78%)

16.96 hits per line