Set the base_url flag in Jupyter Pod

[kimwnasptd]

Following my answer from here the Jupyter Pod needs to be aware of the prefix it is exposed from. For this, we need to use the flag --NotebookApp.base_url to set the prefix to Jupyter. This flag can be set with two ways:

1. As part of the jupyter command, jupyter notebook --ip='*' ... --NotebookApp.base_url=...
2. Create a jupyter config file at .jupyter/jupyter_notebook_config.py as shown here

With these I can think of three approaches we could take:

1. Edit images entrypoint and pass the base_url flag in Pod Args

The Controller will set the base_url flag in the PodSpec args. Since k8s args translates to CMD in docker, we need to integrate the CMD inside of ENTRYPOINT in the images' Dockerfile, so that args won't override it.

Changes to be made:

• the Controller sets the args in the PodSpec to args: ["--NotebookApp.base_url=/notebook/<ns>/<nb>/"]
• Remove CMD from images Dockerfile and make ENTRYPOINT:

ENTRYPOINT ["tini", "--", "sh","-c", "jupyter notebook --notebook-dir=/home/jovyan --ip=0.0.0.0 --no-browser --allow-root --port=8888 --NotebookApp.token=''"]

2. Load the prefix with an ENV Var in the images' ENTRYPOINT/CMD

Here we preserve the CMD and use an ENV Var to load the value of the prefix. We use this var in the CMD to put the prefix's value in the base_url flag. The Controller needs to set this ENV Var in the PodSpec.

Changes to be made:

• the Controller sets ENV Var JPY_PREFIX (ex) in the PodSpec with value /notebook/<ns>/<nb>/
• Preserve the CMD and use the mentioned ENV Var

CMD ["sh","-c", "jupyter notebook --notebook-dir=/home/jovyan --ip=0.0.0.0 --no-browser --allow-root --port=8888 --NotebookApp.token='' --NotebookApp.base_url=$JPY_PREFIX"]

3. The Controller creates the config python file and mounts it

Create the configuration file in the controller and inject it in the Pod so that it can be picked up when jupyter starts.

Changes to be made:

• The Controller creates a python file with contents c.NotebookApp.base_url="/notebook/<ns>/<nb>/"
• The Controller mounts it under /home/jovyan/.jupyter/jupyter_notebook_config.py with a ConfigMap.

These are some reasonable approaches that come to my mind, but of course not the only ones we can take. Do you think we could set the base_url in another way in the Jupyter Pod?
What are your thoughts on this @jlewi @lluunn @zabbasi ?

[kimwnasptd]

/cc @jlewi
/cc @lluunn
/cc @zabbasi

[lluunn]

I think 3 seems better because making less assumption on the image.

[kimwnasptd]

For more context:

• kubeflow/kubeflow#2517(review)
• kubeflow/kubeflow#2456
• kubeflow/kubeflow#2456(comment)
• kubeflow/kubeflow#2463(review)

From the last one I understand that we don't want to make assumptions/add options that make sense in a specific context ex. jupyter lab. But this option is not for a specific frontend/extension of jupyter but a required option for the Pod to work properly (under a prefix).

Every app that is exposed behind a prefix needs to be aware of that prefix, whether this app is the jupyter-web-app, our Jupyter Pods or a future image with a different kernel. I can understand the point that the controller should make as little assumptions as possible and I think we should clarify the responsibilities of the image and the controller:

Image:

• Τhe image should work out of the box
• The image should know that it might be exposed under a prefix
• The image can expect that this prefix info will be available to it
• Τhe user should be able to alter the image's behavior (for example use ntract by passing an env var)

Controller:

• The Controller expects that the image works out of the box
• The Controller is responsible for providing the prefix information to the Pod

I think the approach that best aligns with this line of thinking, from the three proposed above, is the second one. The image must work by default and it should expect to find the necessary prefix information under an agreed environment variable.

To make sure everything works out of the box, we will set this ENV var inside the Dockerfile to be "/". This way our kubeflow images will work out of the box, even without the controller, so anyone can just download and try them out.

Now, if an image must run under a specific prefix, the controller will just set this environment variable in the Pod and expect the image to pick it up and configure itself to work properly based on this info. This also aligns with 2456 and 2463.

We could even give this variable a kubeflow specific name like $NB_PREFIX (ex) to also make the var name "independent" from the underlying image. This way even if someone would like to create their own image they know that the prefix will always be available to them through this ENV Var.

[jlewi]

@kimwnasptd's plan seems good to me.

Perhaps we could also start a markdown doc capturing the requirements for jupyter images to work with Kubeflow.

[lluunn]

SGTM
@zabbasi could you make the change to the image?
I will fix the controller part.

[jlewi]

I tried it out

https://kf-vmaster-n02.endpoints.kubeflow-ci.cloud.goog/
git label: v0-4-0-rc-1-192-g20431c4

When I access Jupyter I get

Jupyter Notebook
404 : Not Found
You are requesting a page that does not exist!

So I think traffic is now reaching the notebook. And we probably just need to fix the Docker image to set base_url.

[zabbasi]

/close

[k8s-ci-robot]

@zabbasi: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.