From 9719e4de9df938ffbbd2176eebc91f122911653c Mon Sep 17 00:00:00 2001 From: Nolan Brubaker Date: Tue, 31 Mar 2020 18:06:54 -0400 Subject: [PATCH] Don't defer cancelFunc, since it causes issues Infomers won't start if cancelFunc is invoked as soon as the newServer function exits via the defer Signed-off-by: Nolan Brubaker --- pkg/cmd/server/server.go | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/pkg/cmd/server/server.go b/pkg/cmd/server/server.go index c91f9f6bf..9b06cf29d 100644 --- a/pkg/cmd/server/server.go +++ b/pkg/cmd/server/server.go @@ -270,11 +270,15 @@ func newServer(f client.Factory, config serverConfig, logger *logrus.Logger) (*s return nil, err } + // cancelFunc is not deferred here because if it was, then ctx would immediately + // be cancelled once this function exited, making it useless to any informers using later. + // That, in turn, causes the velero server to halt when the first informer tries to use it (probably restic's). + // Therefore, we must explicitly call it on the error paths in this function. ctx, cancelFunc := context.WithCancel(context.Background()) - defer cancelFunc() clientConfig, err := f.ClientConfig() if err != nil { + cancelFunc() return nil, err } @@ -282,6 +286,7 @@ func newServer(f client.Factory, config serverConfig, logger *logrus.Logger) (*s if features.IsEnabled("EnableCSI") { csiSnapClient, err = snapshotvebeta1client.NewForConfig(clientConfig) if err != nil { + cancelFunc() return nil, err } }