Workbenches and data

Labs 7–11: workbench types with GPU profiles, S3 data connections, workbench storage, a GPU sanity check and Git with Elyra.

Updated CompTech Team

Workbenches are where most users spend their day. These labs cover the environments, where their data comes from and where it is stored.

Every lab assumes the environment described in the series overview. Commands and names are examples: replace them with your own.

Labs in this section

Lab 7: Jupyter, VS Code and RStudio workbenches

Goal: Start each workbench type with CPU and GPU profiles and learn what persists between restarts.

Prerequisites

  • Labs 3–5

Environment notes

RStudio images may need to be built by an administrator before they appear. Workbenches stop and start; only the home volume persists.

Steps

  1. Create a data science project.
  2. Start a Jupyter workbench with the CPU profile, then a VS Code workbench with the time-sliced GPU profile.
  3. Build or enable the RStudio image and start one.
  4. Create a file, stop the workbench, start it again and check the file.
  5. Install a package with pip, restart and note it is gone unless installed into the home volume.

Verification

  • All three workbench types reach Running and open in the browser.
  • Files on the home volume survive a restart.

Lab 8: S3 data connections with NooBaa and ONTAP S3

Goal: Connect workbenches, pipelines and model servers to object storage without putting keys in notebooks.

Prerequisites

  • Lab 7
  • An S3 endpoint: the Multicloud Object Gateway (NooBaa) from ODF, or an ONTAP S3 server on an SVM

Environment notes

Use ObjectBucketClaim for NooBaa buckets. Internal endpoints often use a private CA, so add the CA bundle to the cluster trust or the connection. Connections are stored as secrets in the project.

Steps

  1. Create a bucket with an ObjectBucketClaim and read its generated secret and config map.
  2. Add an S3 connection in the project with endpoint, region, bucket and keys.
  3. Attach the connection to a workbench and read the injected AWS_* environment variables.
  4. Upload and list objects with boto3.
  5. Repeat with an ONTAP S3 bucket and compare.

Verification

  • A notebook can write and read an object using only the injected variables.
  • No credential appears in a notebook or Git.

Lab 9: Workbench storage: ontap-nas, ontap-san, ODF and RWX

Goal: Choose the right storage class for home volumes, datasets and shared folders.

Prerequisites

  • Lab 7
  • Trident with ONTAP NAS and SAN backends, and ODF

Environment notes

NAS (NFS) and CephFS support ReadWriteMany; SAN (iSCSI/NVMe) and Ceph RBD are ReadWriteOnce block volumes with lower latency.

Steps

  1. Create workbenches whose home volumes use ontap-nas, ontap-san and ODF RBD.
  2. Run a simple fio or dd test in each and record throughput and latency.
  3. Create an RWX volume on ontap-nas or CephFS and mount it in two workbenches.
  4. Expand a volume from the dashboard and check the filesystem grows.
  5. Snapshot a volume and restore it into a new claim.

Verification

  • You have a results table and a recommended default class for each use.
  • Two workbenches see each other's files on the RWX volume.

Lab 10: GPU sanity check in a notebook

Goal: Prove a workbench really has a GPU and understand what time-slicing looks like from inside.

Prerequisites

  • Labs 3 and 7

Environment notes

With time-slicing, several pods share one L40S with no memory isolation: each sees the full 48 GB, and nvidia-smi shows other tenants' processes only in some setups.

Steps

  1. Start a CUDA PyTorch workbench with the full-GPU profile.
  2. Run nvidia-smi, then torch.cuda.is_available() and torch.cuda.get_device_name(0).
  3. Time a large matrix multiplication on CPU and GPU.
  4. Repeat on two workbenches sharing one GPU through the time-sliced profile and compare timings.
  5. Allocate memory in both until one fails, and note the error.

Verification

  • PyTorch sees an NVIDIA L40S.
  • You can show the slowdown and memory risk of sharing a card.

Lab 11: Git integration and Elyra pipelines

Goal: Work from Git in a workbench and turn notebooks into a pipeline visually.

Prerequisites

  • Labs 7–8
  • A Git server and a pipeline server in the project (Lab 34)

Environment notes

Use HTTPS tokens or deploy keys stored in the workbench, never in notebooks. Elyra needs a runtime configuration that points to the project's pipeline server and S3 connection.

Steps

  1. Clone a repository with the Jupyter Git extension.
  2. Commit and push a change from the workbench.
  3. Open the Elyra pipeline editor and drag two notebooks onto the canvas.
  4. Set each node's image, resources and outputs, then submit the pipeline.
  5. Follow the run in the dashboard.

Verification

  • The commit is visible on the Git server.
  • The Elyra pipeline completes and its outputs are in the bucket.
← PreviousPlatform and administrationNext →Model serving with KServe