Course · RCC ClusterDocs
Class 12: From notebooks to governed project services
Service status: RCC workers and Slurm workflows are ready now. Project vhosts are not yet released; this class prepares an architecture and review package for the future service.
Recommended starting point · 2 min video
Watch the class first
Choosing between notebooks, workflows, and services, with clear boundaries and review preparation. Watch the complete lesson, then use the written page below for copyable commands, exercises, and reference details.
The videos are waiting for publication on the RCC documentation website. This preview deliberately does not link to a local copy or another host. The complete written lesson is available below.
This includes model-backed research services. A trained model, embedding index, or AI inference endpoint inherits the governance of its source data and requires the same reviewable service boundary as any other protected project application.
This class helps you decide when a notebook should remain a notebook, when a Shiny or Python web app is appropriate, and when computation should move into a Slurm workflow.
Learning goals
After this class, you can:
- choose between notebook, batch job, Shiny app, Python web app, and vhost;
- separate interactive presentation from expensive computation;
- package a small service for review;
- write a minimal release note for project users;
- avoid patterns that leak data or overload shared infrastructure.
Decision guide
| Need | Best pattern |
|---|---|
| Explore data and make notes | Notebook in a Slurm allocation |
| Repeat an analysis reliably | Slurm batch job or Snakemake workflow |
| Let a small team adjust parameters interactively | For now, a bounded tunnelled development session; later, an app behind the vhost gateway |
| Publish static instructions or reports | Future static information vhost — not yet released |
| Provide a dashboard against approved data | Future active read-only vhost — not yet released |
| Process large uploads | Future upload vhost plus a ready RCC-worker/Slurm workflow |
Service boundary
A governed web app should be a presentation and coordination layer. It may read approved data, collect small forms, start reviewed workflows, or display curated results. It should not perform long-running analysis inside the web request.
A good pattern is:
- The web app validates input.
- The app writes a small request record.
- A Slurm workflow performs the heavy computation.
- The app displays completed results.
- Logs and receipts keep the action attributable to a named user.
Preparing for future vhost review
Before asking for a vhost, prepare:
- project name and project lead;
- who may access the application;
- whether it is static, read-only, standard, or upload-capable;
- the deployment source and version;
- data sources and whether they contain sensitive content;
- resource expectations;
- support contact and review date.
Completion gate
Use the vhost request checklist from Class 8 and add one architectural sentence:
Heavy computation for this service will run through Slurm, while the web app only handles authentication, parameter collection, status display, and curated result access.
If that sentence is false, redesign the application before requesting a vhost.
Self-check questions
- What is the risk of doing large computation inside a web request?
- Why should project access be granted through group membership instead of account sharing?
- How does a vhost differ from a tunnelled notebook or Shiny session?
- What evidence should be available after a user uploads or downloads data?