From 6767dff146900aa14a5d0ab3854e70e63dd6c7d9 Mon Sep 17 00:00:00 2001 From: FillZpp Date: Tue, 17 May 2022 13:56:44 +0800 Subject: [PATCH] Fix comment on LeaderElectionResourceLock Signed-off-by: FillZpp --- pkg/manager/manager.go | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/pkg/manager/manager.go b/pkg/manager/manager.go index 5f76b5a836..45348794ba 100644 --- a/pkg/manager/manager.go +++ b/pkg/manager/manager.go @@ -142,18 +142,31 @@ type Options struct { LeaderElection bool // LeaderElectionResourceLock determines which resource lock to use for leader election, - // defaults to "configmapsleases". Change this value only if you know what you are doing. + // defaults to "leases". Change this value only if you know what you are doing. // Otherwise, users of your controller might end up with multiple running instances that // each acquired leadership through different resource locks during upgrades and thus // act on the same resources concurrently. - // If you want to migrate to the "leases" resource lock, you might do so by migrating to the - // respective multilock first ("configmapsleases" or "endpointsleases"), which will acquire a - // leader lock on both resources. After all your users have migrated to the multilock, you can - // go ahead and migrate to "leases". Please also keep in mind, that users might skip versions - // of your controller. // - // Note: before controller-runtime version v0.7, the resource lock was set to "configmaps". - // Please keep this in mind, when planning a proper migration path for your controller. + // If you are using `configmaps`/`endpoints` resource lock and want to migrate to "leases", + // you might do so by migrating to the respective multilock first ("configmapsleases" or "endpointsleases"), + // which will acquire a leader lock on both resources. + // After all your users have migrated to the multilock, you can go ahead and migrate to "leases". + // Please also keep in mind, that users might skip versions of your controller. + // + // Note: before controller-runtime version v0.7, it was set to "configmaps". + // And from v0.7 to v0.11, the default was "configmapsleases", which was + // used to migrate from configmaps to leases. + // Since the default was "configmapsleases" for over a year, spanning five minor releases, + // any actively maintained operators are very likely to have a released version that uses + // "configmapsleases". Therefore defaulting to "leases" should be safe since v0.12. + // So, if your operator is still using a controller-runtime version before v0.7 and you + // didn't set the LeaderElectionResourceLock, you could take these steps to upgrade + // the dependency to v0.12 or newer: + // 1. update controller-runtime in go.mod to v0.12 or newer + // 2. set LeaderElectionResourceLock to "configmapsleases" + // 3. package your operator and upgrade it for all your clusters + // 4. only if you have finished 3, you can remove the LeaderElectionResourceLock to + // use the default "leases" LeaderElectionResourceLock string // LeaderElectionNamespace determines the namespace in which the leader