Lease TTL resetting on leader elections or single-node restart, but it isn't doccumented

[mgates]

Hey Folks,

https://github.com/coreos/etcd/blob/master/lease/lessor.go#L343 Seems to indicate (and some initial testing confirms) that every time there is a leader election (which happens on cluster restart), all of the leases get re-set to the current time plus the initial TTL (plus the leader timeout).

So, two questions:

Why is this needed? It makes sense to me that we have to extend the time by the amount of time which the old leader would take to start rejecting attempts to extend a lease, but it seems to be that that that would never be longer than the leader election timeout. Re-setting all the leases to the initial TTL seems very heavy handed.

I couldn't find any discussions of this in the docs. It was pretty unexpected to us to find that leases might never expire if there were enough leader elections, so if this is deliberate, I think it merits some talk in the docs.

Thanks for the clarification.

[xiang90]

It is needed since only the leader records TTL for performance reasons. It wont be changed.

We should document it though. But if you expect the leader changes much more frequent than lease can expire, you have to either make your cluster more reliable or shorter the lease.

[xiang90]

in another word, etcd lease is for short period keepalive in the range of seconds or minutes at max. not for hours or days.

[mgates]

Thanks for the explanation!