Reconsidering manual server linkage

[rcthomas]

In #51 we added a property linking the child spawner's server. About the same time, jupyterhub/jupyterhub#3810 was merged to keep Spawner.server in sync with underlying orm_spawner.server and that PR was referenced in the discussion on #50 and #51. Folks tested #50 and #51 against JupyterHub setups that I don't think included the server sync fix.

While catching up on my deployment this week I noticed I was still running off the branch in #50 (with the strange hack), and when I tried to run off current wrapspawner master it failed to spawn properly. Specifically, during spawn the Hub reports that it expects the spawner on the wrong URL (as reported from here), namely a URL that corresponds to the hub itself.

In the discussion on #50 Min mentioned that the server sync fix may be all that was necessary so I decided to follow-up on that conjecture, and I reverted #51 (equivalent to just running the latest release, 1.0.1), and for me things now seem to be working again. I think #51 somehow conflicts with jupyterhub/jupyterhub#3810 but may be obviated by it anyway.

We probably want to consider reverting #51, but I think others should test. Basically the question is whether #51 breaks anything for anyone running JupyterHub 2.2.0 or later.

[rcthomas]

I've tested JupyterHub versions 2.0.2, 2.1.1, 2.3.1 are all OK with wrapspawner 1.0.1. But those versions are not OK with the most recent commit that adds the server properties. These tests were fairly easy because I just walked back my existing JupyterHub 2.x configs, but I'm wondering if someone else could check on say the latest Hub 1.x the same way.

[alibi1125]

I can confirm that #51 breaks (and reverting it fixes) the spawning behavior on JupyterHub 2.3.1 for me as well. Can't say anything for JupyterHub 1.x, though. If you want me to do some further digging or require additional info on our setup, please let me know.

[octomike]

This day's rabbit hole brought me here - upgraded to JupyterHub 3.0.0 today and found this is still an issue.

[rcthomas]

@octomike could you give us a little more info there?

• You said you upgraded to 3.0.0 today, what version were you running before?
• What version of wrapspawner is causing you issues? The release or the master branch?

[octomike]

Sure thing!

I moved from an ancient JH 1.1.0 and I tried wrapspawner@master first.

[rcthomas]

OK, and you'd been using that version of wrapspawner before the upgrade? Thanks!

[octomike]

OK, and you'd been using that version of wrapspawner before the upgrade? Thanks!

Nope, we also had an older one (versioned as 0.0.1.dev0) before.

[Ph0tonic]

Hi,
I confirm that reverting #51 is necessary and that wrapspawner works correctly without this patch. Here is a PR to reverse this:

• Reverse patch server #51 #60

It would be nice to be able to move forward. 👍

\cc @mbmilligan