Change:
What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): "lock is held by" "has not yet expired" Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): tested on 1.3.5 and 1.3.8 (upgraded today) Environment: Hardware: vmware guest OS: CoreOs 1122.2.0 kernel: 4.7.0-coreos masters: 3 /etc/kubernetes/manifests/kube- looks like this: /etc/kubernetes/manifests/kube-controller- looks like this: What happened: The logs from kube-scheduler and kube-controller-manager are spamming with: The node holding the lock only logs this: What you expected to happen: If this is expected behaviour i would like to be able to supress those messages with --v=2 How to reproduce it (as minimally and precisely as possible): I think it would be sufficient to run scheduler or controller-manager with . etcdctl get registry/services/endpoints/kube-system/kube-controller-manager looks like this: The cluster seems healthy and are scheduling pods correctly.
Same issue with 1.4.4
Just hit this with 1.4.6 as well.
To state that the spam is overwhelming would be a vast understatement. It dominates all log entries by a factor of 7. Please do something about this sooner rather than latter.
This is expected behavior, this appears from standby controllers and schedulers. You can tune these parameter on the binaries.. see leader-election params under --help. closing, not an bug
i cannot find any way to supress this exept turning upp the duration and thats not what we want. I only dont want to fill elasticerarch with those messages. Why dont they have a proper loglevel there? When this which seems like an error has a higher log level?
K, I'll adjust the log levels.
Does the controller-manager start with by default? Did I understand this correctly that you moved it to ? Does this by chance have anything to do with the log for Ingress controllers as well and will be fixed in 1.6 ?
default depends on provider, some folks default to 3. Needless to say -v 4 "should be" outside the normal range to prevent spamming. verbosity on ingress controller is controlled by how that component is started, but I applied it to the base so it should hit *.

Discussion:
// acquire loops calling tryAcquireOrRenew and returns immediately when tryAcquireOrRenew succeeds. func (le *LeaderElector) acquire() { stop := make(chan struct{}) <ins> glog.Infof("attempting to acquire leader lease...") </ins> wait.JitterUntil(func() { succeeded := le.tryAcquireOrRenew() le.maybeReportTransition() desc := le.config.Lock.Describe() if !succeeded { <del> glog.V(4).Infof("failed to renew lease %v", desc) </del> <ins> glog.V(4).Infof("failed to acquire lease %v", desc) </ins> return } le.config.Lock.RecordEvent("became leader")

} if le.observedTime.Add(le.config.LeaseDuration).After(now.Time) && oldLeaderElectionRecord.HolderIdentity != le.config.Lock.Identity() { <del> glog.Infof("lock is held by %v and has not yet expired", oldLeaderElectionRecord.HolderIdentity) </del> <ins> glog.V(4).Infof("lock is held by %v and has not yet expired", oldLeaderElectionRecord.HolderIdentity) </ins> return false }