-
Notifications
You must be signed in to change notification settings - Fork 309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Existing stopped container is not removed when newly requested image is different and remove = False
#423
Comments
Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗 |
There was a discussion on the community forum recently: Setting |
Hey @manics hadn't seen that forum post so thanks for the link. Was an interesting read. Will add a new post (and link back here) as it's not exactly the same. Still think that this is weird/unexpected behaviour that should be handled if |
This issue has been mentioned on Jupyter Community Forum. There might be relevant details there: |
Summarizing what I think we should do from the forum:
There is no general 'home directory' persistence that will work in general, but we can pick a default that works for jupyter docker-stacks and make it easy to override. KubeSpawner's been doing this for ages and it works great. |
Bug description
Previously stopped container
1
derived from imageA
that is different to the latest imageB
chosen by a user from the options form is not removed when it should be in order to create container2
. Instead, container1
is simply restarted.Potential FIx
An additional
if
block can be added around here:Can put together a PR. Just tested by editing current master branch install on the host myself and works perfectly well (although
jouranlctl
doesn't seem to be logging things correctly).Expected behaviour
A user stopping their server and selecting image
B
should cause the existing stopped container1
based on imageA
to be removed and a new container2
created based on imageB
.Actual behaviour
A user stops their server and selects image
B
but existing container1
is restarted.How to reproduce
With
c.Spawner.remove = False
andc.Spawner.allowed_images = {image_name_a: image_a, image_name_b: image_b}
and a Lab ide.Start Server
and selects imageA
in the option formStop My Server
Start Server
and selects imageB
in the option form1
as before (original container1
is not removed)Your personal set up
Full environment
Container installs (we use custom images available at dockerhub and/or GitHub):
Configuration
Output of:
$ grep -v '\(^#\|^[[:space:]]*$\)' /etc/jupyterhub/config.py
Logs
journalctl -u jupyterhub
since last hub restart:Second container start doesn't seemed to be caught by logs and/or our server's journalctl isn't updating.
The text was updated successfully, but these errors were encountered: