How To
Summary
This document describes how to access an NFS share in Watson Studio Local environments
Objective
Environment
Steps
Executive summary
The high-level solution is to mount the Network File System to the same folder on every Watson Studio Local virtual machines, and then add the mount point in runtime definition files. There are two types of runtime definitions in Watson Studio Local, built-in and custom. The built-in runtime definitions are stored as a Kubernetes configmap, and the custom runtime definitions are stored as regular files. Modifying the built-in runtime definitions may work as a short-term solution, but the changes could be wiped out during an upgrade, so the best practice is to modify a custom image.
Instruction on how to build a custom image as an admin user in WS Local: https://content- dsxlocal.mybluemix.net/docs/content/local/images.html
Instruction on how to build a custom image as a regular user in WS Local: https://content- dsxlocal.mybluemix.net/docs/content/analyze-data/save-images.html
Steps to mount the Network File System
1. Mount the Network File System to every Watson Studio Local virtual machines
For each NFS, make sure to use the same folder as mount point on every WS Local virtual machines. In this document, we assume a NFS is set up and mounted to the same mount point /examples on every WS Local virtual machines.
2. Edit the runtime-definition files for custom images
Create a custom image, follow the instructions provided above. Go to a running image-mgmt pod
. Inside the pod, go to the custom runtime-definition folder cd /user-
home/_global_/config/.runtime-definitions/custom/.
One image can have multiple runtime-definition json files, for example, the following Jupyter image with python 2.7 has 3 runtime-definitions, the first one is for worker job, the second one is for environment, the third one is for script as a service. It is highly recommended to modify all the runtime definitions for the same custom image.
In this example, we'll only modify the environment one, vi arrow-image-v1.0-jupyter- server.json, add the following to the "volumes" field.
“volume” is the path on the virtual machine (the mount point created in step 1) “mountPath” is the path inside the runtime container (e.g. the path to use in a notebook) “type”: “hostPath” is the keyword to mount the host path into the container.
kubectl -n dsx exec -it $(kubectl -n dsx get po |
grep image | grep Running | awk '{print $1}' | head -1) sh
/user-home/_global_/config/.runtime-definitions/custom # ls | grep arrow arrow-image-v1.0-dsx-scripted-ml-python2-server.json arrow-image-v1.0-jupyter-server.json arrow-image-v1.0-python27-script-as-a-service-server.json
{
"volume": "/examples", "mountPath": "/external-fs", "type": "hostPath"
}
3. Create a notebook and use the mounted path
Modify the Jupyter with python 2.7 environment to use the custom image.
Create a notebook using the modified environment.
4. Steps to undo the changes
Stop the runtime environment in step 4 before going forward.
Remove the extra volume field in the runtime definition files in step 3, or delete the custom image if it’s no longer needed. To delete a custom image:
- Log in as an admin user, go to Admin Console and select Image management from sidebar
In the image management page, select Delete from the ‘Action’ button at the end of the image’s row
Document Location
Worldwide
Was this topic helpful?
Document Information
Modified date:
30 December 2019
UID
ibm10870064