search

jupyterhub / wrapspawner

Mechanism for runtime configuration of spawners for JupyterHub
BSD 3-Clause "New" or "Revised" License
59 stars 57 forks source link

JupyterHub using start_timeout from ProfilesSpawner rather than target spawner. #18

Open GrahamDumpleton opened 6 years ago

GrahamDumpleton commented 6 years ago

I do need to go back and verify this again, but recording it as issue so don't forget until I can.

What I observed a while back is that JupyterHub will use start_timeout from spawner instance for a specific timeout. When using ProfilesSpawner this is an issue as it ends up using start_timeout from the Spawner base class, rather than what start_timeout may be defined in the target spawner chosen.

The result of this was that couldn't use start_timeout in the profile or by doing:

c.KubeSpawner.start_timeout = 120

It was necessary to use:

c.Spawner.start_timeout = 120

If observation is right, ProfilesSpawner should perhaps override start_timeout as a property and get start_timeout from the target spawner which was chosen.

jcwomack commented 2 months ago

I have just encountered this issue on with wrapspawner v1.0.1, when using ProfilesSpawner to allow a choice of batchspawner.SlurmSpawner configurations.

I tried setting the start_timeout configuration attribute for a few different Spawner subclasses, to see where the setting would get picked up. I tried

Of those, only setting c.Spawner.start_timeout, c.WrapSpawner.start_timeout, and c.ProfilesSpawner.start_timeout had any effect. Given the class inheritance relationship between these is Spawner -> WrapSpawner -> ProfilesSpawner, it seems that JupyterHub is using the start_timeout value from ProfilesSpawner (when c.JupyterHub.spawner_class = 'wrapspawner.ProfilesSpawner'), rather than any child spawner class. This has the effect that child (wrapped) spawners cannot set individual start_timeout values.