JupyterHub using start_timeout from ProfilesSpawner rather than target spawner.

[GrahamDumpleton]

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]

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

• c.Spawner.start_timeout
• c.BatchSpawnerBase.start_timeout
• c.SlurmSpawner.start_timeout
• Setting the start_timeout in the dict of spawner config options in c.ProfilesSpawner.profiles
• c.WrapSpawner.start_timeout
• c.ProfilesSpawner.start_timeout

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.