I started off by adapting the leaderelection module from kubernetes-client/python, but keeping the implementation as similar as possible. I'm not sure to what extent this project aims to provide a similar interface to kubernetes-client/python, and I'll call out some concerns I have in comments on the changed code.

Codecov Report

Attention: Patch coverage is 61.79487% with 149 lines in your changes missing coverage. Please review.

Project coverage is 27.05%. Comparing base (3ab6408) to head (bed4ae1).

@@            Coverage Diff             @@
##           master     #347      +/-   ##
==========================================
+ Coverage   26.91%   27.05%   +0.13%     
==========================================
  Files         799      805       +6     
  Lines       98316    98706     +390     
==========================================
+ Hits        26463    26704     +241     
- Misses      71853    72002     +149     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I started off by adapting the leaderelection module from kubernetes-client/python, but keeping the implementation as similar as possible. I'm not sure to what extent this project aims to provide a similar interface to kubernetes-client/python, and I'll call out some concerns I have in comments on the changed code.

No worries, I usually adapt with modifications. Thanks!

• I've incorporated the leaselock module from add support Lease-based leader election (rather than ConfigMaps) #1877 kubernetes-client/python#2314 with minimal adjustments.
• What do you think about the loglevels (mostly INFO)? I've preserved the log messages and levels used in kubernetes-client/python, but I wonder if some are a bit verbose.

What do you think about the loglevels (mostly INFO)? I've preserved the log messages and levels used in kubernetes-client/python, but I wonder if some are a bit verbose.

I agree, some of them should be on debug level...

What do you think about the loglevels (mostly INFO)? I've preserved the log messages and levels used in kubernetes-client/python, but I wonder if some are a bit verbose.

I agree, some of them should be on debug level...

I switched to a mix of debug for verbose debug conditions, and error/exception for messages that actually indicate problems. Let me know if you agree with the selections.

I also made an unrelated change in ef01ee6, switching the callback functions from Callable[..., Coroutine] to Coroutine, to facilitate context passing at the time of leader election establishment. I realized this would be useful as I wrote some code using the contents of this PR, and noticed that it'd be nice if there were an easier way to pass context to onstarted_leading. For example, the ApiClient used to establish the leader election:

    async with api_client.ApiClient() as apic:
        # Create config
        leader_election_config = electionconfig.Config(
            # A legacy ConfigMapLock is also available
            LeaseLock(lock_name, lock_namespace, candidate_id, apic),
            lease_duration=17,
            renew_deadline=15,
            retry_period=5,
            onstarted_leading=example_start_func(api_client=apic),
            onstopped_leading=example_end_func(),
        )

        # Enter leader election
        await leaderelection.LeaderElection(leader_election_config).run()

This seemed to be much more pleasant than other options for including arbitrary context, such as defining otherwise-unnecessary wrapper functions, using contextvars, etc.

Let me know what you think.

I see two potential problems with passing coroutines:

1. coroutines can be awaited only once so in an application you may need to recreate callbacks every time

2. ugly messages from python if they aren't awaited

what about supporting two versions? we can check if it is a function or a coroutine and act accordingly.

what about supporting two versions?

For the function version, are you suggesting supporting non-async functions, or supporting async functions (that return coroutines)?

what about supporting two versions?

For the function version, are you suggesting supporting non-async functions, or supporting async functions (that return coroutines)?

async functions and coroutines:

onstopped_leading=example_end_func,

# or:

onstopped_leading=example_end_func(),

# where:

async def example_end_func():
    pass