DockerSpawner plans - bring into line with other Spawners, instead of committing new image

[danlester]

JupyterHubs using DockerSpawner are currently treated differently to any other spawner type (e.g. KubeSpawner or LocalProcessSpawner). This was to provide extra functionality available from Docker - it clones the entire environment from a 'source server' selected by the user. This means any recently installed packages make it into the dashboard server, and also that any files stored in the environment (instead of the user's home folder) are copied into the dashboard server.

While this approach could be useful, in practice it doesn't reflect how JupyterHubs are used.​​ Script files and notebooks are usually stored in the user's home folder which is shared between Jupyter servers - so the dashboard server will normally just access a copy of the scripts on a volume shared between all of that user's servers. Similarly, most packages required by the scripts will be installed into the base Docker image rather than installed only in the container they are currently using.

Dashboard configuration (such as the starting script/notebook and presentation framework type) are baked into the committed ​​Docker image. The dashboard server is then just configured to use this new image, but otherwise runs much like a regular Jupyter server.

The other spawners work differently, doing more work at spawn-time to adjust the commands being run to start the presentation server (e.g. running voila or streamlit instead of jupyter).

My plan is to bring DockerSpawner in line with the other spawners. This will mean a single (simpler) entrypoint will be required in the Docker image, and a new VariableDockerSpawner wrapper class will need to be specified in your JupyterHub instead of the regular DockerSpawner.

The upgrade path should not be difficult, but may introduce breaking changes if this change is introduced without a bit of care at upgrade time.

If anyone is using DockerSpawner I would really like to hear your thoughts - especially if the approach described above does or does not reflect how you tend to use your Jupyter servers and Docker images.

[danlester]

In the end, no special entrypoint is required at all beyond the usual one in the Jupyter Docker images.

[danlester]

Will be incorporated into version 0.1.0 of cdsdashboards.