-
-
Notifications
You must be signed in to change notification settings - Fork 91
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
Add persistent volume configuration to jupyter #78
base: main
Are you sure you want to change the base?
Conversation
initContainers: | ||
- name: {{ .Release.Name }}-jupyter-volume-permissions | ||
image: busybox:1.31.1 | ||
command: ["sh", "-c", "chmod -Rv 777 /data/ && chown 0:100 -R /data/"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting permissions to 777 is generally a bad idea. You may find 755 is more appropriate.
However could you provide a little explaination why this is necessary at all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The storage class that I am using is longhorn. The volumes they give you are owned by root by default. That init container sets the permissions so that the jovyan user can read and write to the PV.
I'm not aware of any storage classes that let you explicitly set the default ownership. I will add an option so its easy to disable this init container if desired.
dask/values.yaml
Outdated
enable: false | ||
storageClass: "default" | ||
size: 1Gi | ||
path: /home/jovyan/persistent |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would recommend making this just /home/jovyan
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to explicitly not overwrite the examples directory with the pv. I see your point though, it would be much clearer to the user if the entire home directory is whats saved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The examples are created at runtime. So this should've be a problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I make the mount path /home/jovyan
the examples do not show up.
Checking the Dockerfile from the dask-docker
repo shows they are added at build time.
https://github.com/dask/dask-docker/blob/master/notebook/Dockerfile#L47
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh interesting. I must be thinking of the Pangeo helm chart.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering how you want to handle this. I can submit a PR to the docker-helm repo to copy the examples to another directory (say /usr/share/doc/dask-examples). That way they would be independent of the PV, and always available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @jacobtomlinson how would you wan tot handle this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can submit a PR to the docker-helm repo to copy the examples to another directory (say /usr/share/doc/dask-examples).
The trouble with this is discoverability. Really they need to show up in the sidebar.
Perhaps adding them to that location and then adding a line to the prepare.sh
script to create a symbolic link would work?
This looks like a good change. Just a couple of comments. |
I have a way to do this on AWS s3 |
That's great @joehoeller! Would you mind sharing your method? Perhaps we could add it to the docs. |
Yeah let’s connect.
I also have another question in LinkedIn that I tagged you in.
…On Wed, Dec 2, 2020 at 10:57 AM Jacob Tomlinson ***@***.***> wrote:
That's great @joehoeller <https://github.com/joehoeller>! Would you mind
sharing your method? Perhaps we could add it to the docs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#78 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABHVQHF44HNJ6XL2QWFRZ2TSSZWY3ANCNFSM4OWFXZPQ>
.
|
Yeah I spotted the SO question. I've answered it. Are you able to share things publicly here? It would be great for the community. |
Persistent Volumes for Jupyter using RAPIDS and Dask with Amazon s3 The instructions for Dask are not obvious, however it does say to install on both worker and jupyter server nodes: Inside
Then, inside the path You will see these vars:
|
@jacobtomlinson did this work for you? I noticed my version I forked internally has a slightly diff file structure. |
@jacobtomlinson can i close this? |
I was having issues with the jupyter where any notebooks saved were lost any time the pod kicked over. I've added some very simple configuration to add a persistent volume claim to the jupyter instance (which is disabled by default).
I've made it so that you can specify where the volume gets mounted, the size, and the storage class. When the storage class name is "default", it will use whatever the default storage class is.