restricting port range for spawned jupyterhub singleuser servers

[jupyterhub]

restricting port range for spawned jupyterhub singleuser servers

[rkdarst]

Hi,

This seems like a good idea overall. I'll leave some comments in the diff, but note that I'm not actually a batchspawner developer but have done a lot of work in it. (There isn't any current way to do this, unless OS can control the default bind ports and thus affect the behavior of jupyterhub.utils.random_port).

My first thought was "this would be good to add to jupyterhub", but randomly checking two spawners show there isn't necessarily a lot of overlap. Plus it would require many jupyterhub releases before it could be relied on here anyway. Plus there's no default way for random_port to get info from the spawner options...

Have you seen #58? It is somewhat related in that it is about more clever port selection, but not limiting that selection. If we ever made progress on that, we should put these two together.

I'll highlight @minrk since it possibly relates to jupyterhub itself. (btw, abstractly I still want to integrate #58 with JH but it's been slow going)

[mbmilligan]

I think the most general way to handle this would be for us to pull out the call to jupyterhub.utils.random_port() into a trait or class method that could be overridden during the configuration process. Off the top of my head, I'm thinking we could use a trait that accepts a callable (specified to return a port number), and we could have pre-made callables for common scenarios like "a range of ports" or, once #58 goes through, "use the port selection API."

[rkdarst]

I think @mbmilligan's solution is quite clearly the right one for now...

[rkdarst]

In #114 I implemented @mbmilligan's suggestion.