From f7ed810c21ea8a1711d99a7a6035adf06e9b42d7 Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Tue, 12 Sep 2023 20:40:28 -0500 Subject: [PATCH] server/config: don't render ReadinessIndicatorFile to multus CNI config 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 --- pkg/server/config/generator.go | 3 +++ 1 file changed, 3 insertions(+) diff --git a/pkg/server/config/generator.go b/pkg/server/config/generator.go index db3d61007..a6f15977d 100644 --- a/pkg/server/config/generator.go +++ b/pkg/server/config/generator.go @@ -128,6 +128,9 @@ func (mc *MultusConf) Generate() (string, error) { mc.MultusAutoconfigDir = "" mc.MultusMasterCni = "" mc.ForceCNIVersion = false + // Readiness indicator file existence is already handled by the + // ConfigManager via an fsnotify watch, so CmdAdd/CmdDel don't need to. + mc.ReadinessIndicatorFile = "" data, err := json.Marshal(mc) return string(data), err