LeaderElection: Lease resource left behind

[katheris]

Describe the bug

There is currently no way to have Lease resources automatically cleaned up. There should be a mechanism to provide an owner reference.

Fabric8 Kubernetes Client version

SNAPSHOT

Steps to reproduce

1. Use the client.LeaderElector() function to create a Leader election process.
2. When the application that called this function is no longer running the Lease resource is left behind

Expected behavior

There should be a mechanism to get this Lease resource cleaned up.

Runtime

minikube

Kubernetes API Server version

1.25.3@latest

Environment

macOS

Fabric8 Kubernetes Client Logs

No response

Additional context

No response

[shawkins]

The initial thought was to allow the user to set an owner reference as part of the LeaderElectionConfig. However this functionality is not part of the go client, and given that a likely owner (a Deployment) can be deleted before their underlying pods are fully terminated this leaves open some potentially odd behavior while things are cleaning up (at best the lock would go away, then fail to recreate as the owner no longer exists). I cannot come up with a better built-in alternative though. Any other thoughts from the fabric8 community?

[shawkins]

@katheris the proposal in the pr is to give the user full control over the ObjectMeta used to create the lock in the Lease or ConfigMap lock constructor, does this seem like a good solution for you?