Improve documentation on how singleuser images behave when hub is restarted

[manics]

The default is for spawned images not to be deleted when they're stopped. This can have unexpected effects if the JupyterHub configuration or deployment is changed since the restarted container keeps it's old environment variables and command-line. This means some (is there a list???) of the connection parameters are re-used, but they may be out of date.

See https://discourse.jupyter.org/t/why-does-jupyterhub-not-see-the-docker-network-i-have-created/5275/

Is there a good way to handle this, especially as it's more likely to hit people new to JupyterHub since they're most likely to be playing with their configuration?

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[1kastner]

For me using docker-compose (up/down) and manually deleting docker volumes served the purpose. Maybe that could be a recommendation?

[minrk]

I think a great enhancement would be when a stopped container is about to resume, go through and check for fields that differ from what we would be starting and warn about the differences, and possibly suggesting that the container be removed. We could also have a secondary flag to delete containers that don't match rather than just warning about a likely impending failure.