c.Kubespawner.modify_pod_hook does not support co-routines

Bug description

I am facing an issue when providing a co-routine to c.Kubespawner.modify_pod_hook.

The Tornado docs for gen.maybe_future() say that maybe_future can only handle Futures and no other yieldable objects.

Does this mean, we can pass coros as a hook function? I mean a coro which as been declared via async def ...

Expected behaviour

c.Kubespawner.modify_pod_hook should support co-routines.

Actual behaviour

c.Kubespawner.modify_pod_hook only supports normal functions or futures.

If passed a co-routine, I will pass the co-routine into the Kubernetes client which fails.

How to reproduce

1. Define a co-routine via the async def syntax:

import asyncio

async def my_pod_modify_hook(spawner):
     await asyncio.sleep(1)
     return

c.Kubespawner.modify_pod_hook = my_pod_modify_hook

Your personal set up

A pretty standard Z2JH setup (master)

[minrk]

KubeSpawner should stop using gen.maybe_future and instead rely on from jupyterhub.utils import maybe_future

Yes! That’s the right thing to do.

If you want, though, I don’t think kubespawner needs to be as fully general as jupyterhub’s own implementation, which aims for maximum compatibility to ensure it didn’t break anything when we made the big asyncio transition. If you are a little more strict about what things may return, you can even optimize a bit by avoiding the unnecessary await if it’s not awaitable:

result = some_function()
if inspect.isawaitable(result):
    result  = await result

The only case that won’t handle is concurrent.futures which is not really important to handle yourself because it’s only asking the author of the function to add asyncio.wrap_future() on the end before returning it to kubespawner, if they happen to be using thread pools (tornado’s @run_in_executor helper already does this). The only reason jupyterhub handles this is tornado’s maybe_future handled it before and we wanted to make sure nothing broke.

Or, alternately, for APIs that should always return None:

result = some_function()
if result is not None:
    await result

which is an even cheaper check than isawaitable():

• x is None ~ 30ns
• inspect.isawaitable(x) ~ 700ns
• jupyterhub.utils.maybe_future(x) ~ 2µs (not counting extra await for non-async callables)

(all these timescales are negligible when adding kubernetes API requests to the mix)

[stv0g]

I’m not confident what should be fixed, but perhaps KubeSpawner should stop using gen.maybe_future and instead rely on from jupyterhub.utils import maybe_future? Do you think this makes sense? I’m just guessing.

Yes, I would support this. I could also submit a PR 😃