-
Notifications
You must be signed in to change notification settings - Fork 31
Custom namespace support #101
Custom namespace support #101
Conversation
For testing purposes you can pass the following parameter to the JupyterHub container.
|
/lgtm |
I've tested the resultant image from this change. With the extra permissions, things seemed to work nicely. |
70e8af0
to
02064d2
Compare
The following commands let us deploy to a second namespace (alongside the additional permissions from @mroman-redhat's PR)
The additional privileges of nonroot don't seem that bad -- from the OpenShift blog[1]:
[1] https://www.openshift.com/blog/managing-sccs-in-openshift |
In addition to what @anishasthana said, the thing is that Random UID assignment on pods is an OpenShift thing, thus the KubeSpawner class from jupyterhub doesn't implement it. Meaning that the UID added in the image Dockerfile will always be used, no matter how many pods Jupyterhub will spawn. The One other option would be, since we created the OpenShiftSpawner class for Jupyterhub, implement that same Random UID assignment from OpenShift. However, I believe both will be disconnected implementations and we can face scenarios where the Openshift cluster was deployed with a custom UID range and JH will not sync up these settings. Having that said, I believe the best solution would be to use the |
Signed-off-by: Anish Asthana <anishasthana1@gmail.com>
69b0a1a
to
9ba92a8
Compare
To sum up the latest changes - we figured the problem with SCC errors is that KubeSpawner sets UID to the one of user in the JH container. As each namespace comes with a different range of allowed UIDs, the cross-namespace deployment failed. We just need to make sure the UID is NOT set (i.e. == None) to allow OpenShift generate it correctly. |
lgtm |
This PR will allow us to deploy Juypterhub notebooks to a different namespace than the main server
CC @rimolive