Custom namespace support

[anishasthana]

This PR will allow us to deploy Juypterhub notebooks to a different namespace than the main server

CC @rimolive

[anishasthana]

For testing purposes you can pass the following parameter to the JupyterHub container.

            - name: NOTEBOOK_NAMESPACE
              value: rhods-notebooks

[rimolive]

/lgtm

[crobby]

I've tested the resultant image from this change. With the extra permissions, things seemed to work nicely.

[anishasthana]

The following commands let us deploy to a second namespace (alongside the additional permissions from @mroman-redhat's PR)

# To allow pod creation
oc adm policy add-scc-to-user nonroot -z default -n <notebook-namespace>
# To enable pulling images
oc policy add-role-to-user system:image-puller system:serviceaccount:<notebook-namespace>:default --namespace=<jupyterhub-namespace>

The additional privileges of nonroot don't seem that bad -- from the OpenShift blog[1]:

nonroot provides all features of the restricted SCC but allows users to run with any non-root UID. The user must specify the UID or it must be specified on the manifest of the container runtime.

[1] https://www.openshift.com/blog/managing-sccs-in-openshift

[rimolive]

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 nonroot SCC could give the JH spawner permission to assign their fixed UID, but not root. That's the only relaxed rule compared to restricted SCC (used by default).

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 nonroot SCC.

[vpavlin]

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.

[vpavlin]

lgtm