The lock acquired by tryAcquireOrRenew is released when the leader ends
leadership. However, due to the cancellation of the context, the lock may
be set as an empty lock, so the Update cannot be run normally, resulting
in a failure to release the lock.
Signed-off-by: jackzhang <x_jackzhang@qq.com>
Kubernetes-commit: 8690ff6264cceb38bd81dec99bb8affcc40286a9
This avoids the assumption that the kinds are populated in the schema,
and is arguably a little more efficient also.
Kubernetes-commit: 3bf06ff3a15a2f1fefeb7a70373a92cb4b94818f
This allows the lock to be release normally - even with a
potentially stale lock. This flow should only occur when we're
the lease holders.
Kubernetes-commit: 8160ecfd90284c333101a16bdccd79aacc86360d
The current code simply exits without continuing to renew the lease, which means
participants using a slower lease duration might have to wait multiple minutes
before a new leader is elected. Allow an optional flag to be set on
LeaderElectionConfig that will release the lease when the calling context is
cancelled. Callers *must* ensure their lease guarded code has completed before
the context is cancelled, or other processes may acquire the lease before this
lease has released.
Add an example command that demonstrates how cancellation could be done.
As a convenience to users, make event recorder optional - not all users of the
lock code will need a recorder.
Kubernetes-commit: 09890b6c48da8e85237a5674d6256900f482b0a5
