The current implementation instantiates a fresh context and passes that along to the leaderElection.Run method which strips any loggers that have been passed into the context.
It appears as though a new context is required here to ensure the leader election thread is not affected by parent context's cancellations. So the proposal here is to use a function similar to this one to ensure a logger is configured in the context:
func (cm *controllerManager) createLeaderElectionContext(parentCtx context.Context) (context.Context, context.CancelFunc) {
newCtx, cancel := context.WithCancel(context.Background())
cm.leaderElectionCancel = cancel
var leaderCtx context.Context
if logger, err := logr.FromContext(ctx); err == nil {
// Use existing logger with leader-election name
leaderLogger := logger.WithName("leader-election")
leaderCtx = logr.NewContext(newCtx, leaderLogger)
} else {
// Fallback to manager's logger
leaderLogger := cm.logger.WithName("leader-election")
leaderCtx = logr.NewContext(newCtx, leaderLogger)
}
return leaderCtx, cancel
}
The current implementation instantiates a fresh context and passes that along to the leaderElection.Run method which strips any loggers that have been passed into the context.
It appears as though a new context is required here to ensure the leader election thread is not affected by parent context's cancellations. So the proposal here is to use a function similar to this one to ensure a logger is configured in the context: