Open OnDemand in the Classroom

Centers use several patterns to host classroom workloads on top of OOD. Which one fits depends on your existing computing resources, how many courses you support, and how much variability you can absorb.

Classroom partition on the research cluster. The most common approach. Carve out a Slurm partition or reservation on your existing research hardware; classroom sessions run against those nodes during class hours and yield to research jobs outside them. Low incremental cost, reuses existing ops muscle. Downside: classroom UX is bounded by whatever the research side can spare.

Dedicated classroom cluster. Separate hardware for teaching. Cleanest isolation — a runaway MPI job on the research side can tank a class meeting — and easier to right-size for interactive workloads (less RAM per core, fewer GPUs, lower cost interconnect). Higher capital cost and duplicated ops. Fits centers with heavy classroom load (dozens of courses, thousands of students) or classes whose class-time SLA can not tolerate research-side contention. Some institutions repurpose older HPC resources for this use.

Kubernetes-backed OOD. Interactive sessions run as pods instead of Slurm jobs. Elastic scaling, faster startup, and a natural fit for stateless apps like Jupyter and RStudio. Does not replace Slurm for batch or MPI, so most centers run it alongside rather than instead of. Newer pattern — operational maturity varies more between sites than the older approaches.

Cloud burst. Spin up cloud capacity (AWS ParallelCluster, Azure CycleCloud, GCP) for scheduled class meetings or deadline peaks. Absorbs load spikes without buying hardware and lets you handle uncertain enrollment gracefully. Cost predictability is the catch — a poorly-scoped assignment can burn a semester budget in an afternoon, so gate it with quotas.

Hybrid. Steady-state baseline on-prem, cloud burst for known peaks. Most flexible, also the most moving parts. Sensible once you have outgrown any single pattern above.

At a glance:

Start with the apps that are likely used across many subject areas and instructors already know how to teach with: Jupyter (Python, data science, ML), RStudio (statistics, biostatistics, econ), MATLAB (engineering), and a Linux remote desktop for courses that need GUI tools like ParaView, ANSYS, QGIS, or an IDE. VS Code Server is a strong fifth for CS and computational science.

One pattern that scales in a classroom is containerized environments per course, not shared modules. Give each course a pinned Apptainer/Singularity image or conda environment that is frozen at semester start — reproducibility across weeks matters more than having the newest package.

The Appverse app catalog flags apps tagged "classroom-tested" (validated at higher concurrent-session counts, checked for licensing quirks, and reviewed for student-appropriate defaults); those are a reasonable starting point when you are picking what to pin.

There is no one right way to lay this out, but centers running successful classroom deployments tend to converge on a few moves.

• Keep it simple
• Deploy only the applications needed for classroom use
• Only include announcements/MOTD messages that are relevant
• Limit informational links to relevant materials

Whether you choose a landing page per class or a single simplified classroom instance shared across courses, brand the classroom deployment distinctly (color, header text, favicon) so students, instructors, and helpdesk staff all know at a glance whether they are in the classroom instance or the research portal. This alone cuts a surprising amount of support ticket confusion.

If you run per-class landing pages, treat each dashboard as course-facing UI rather than a general portal. Pin only the apps the course uses and hide the rest with app-level ACLs so students do not wander into research-only tools. If you are on a recent OOD release with the configurable dashboard, a single "Launch Course Environment" button beats a menu of twelve options for a first-week student.

If you run a single classroom instance shared across courses, keep the app selection tighter than your research OOD — surface only what classrooms commonly need — and use Slurm accounts and group-level ACLs rather than per-page app filtering to manage access.

Either way, use the announcements bar and MOTD for course-timed messaging: office hours, assignment deadlines that will drive load, planned maintenance. Give instructors a lightweight way to request an announcement without opening a ticket for each one.

Before (T-12 to T-4): Advertise classroom capabilities and how to request classroom resources. Encourage instructors to request early (with soft deadlines). Send reminders to prior instructors if possible. It is helpful to use an intake form from the start to get the information you need. Also, be sure to have a plan for handling "give me what I had last semester" requests if you have archived previous configurations.

Before (T-6 to T-2 weeks): Meet with the instructor, confirm enrollment, provision the course Unix group and Slurm account, build and freeze the course container, place a Slurm reservation for scheduled class meetings and known assignment-deadline peaks, and run a dry-run session with the instructor and one or two TAs against the actual course materials.

During: Watch concurrent-session and queue-wait metrics, especially the 24 hours before each assignment deadline. Consider holding a standing 15-minute weekly check-in with instructors for the first month — issues surface faster in conversation than in tickets. Keep a rolling changelog so any mid-semester config change is traceable. Plan major upgrades/changes to infrastructure during semester breaks if possible. Notify instructors of any planned outages.

After: Archive or purge course data per your retention policy (communicate this to students before finals, not after), export utilization metrics for center leadership, capture a short "what we would do differently" note with the instructor, release the reservation, and expire the course group.

The gap between "instructor thinks the class is ready" and "sys admin thinks the class is ready" is where most classroom deployments go sideways. Close it with a structured intake, ideally 4–6 weeks before the first class meeting: course number and enrollment, list of apps and packages, largest expected job (cores, memory, GPU, walltime), assignment deadlines (these predict your load peaks), data sources and sizes, roster source (SIS or LMS), and TA list.

The specific form matters less than having one — a shared form or template that lands in your ticket queue is enough. The point is to give both sides the same source of truth about what the semester will demand, and to catch the "we need a 60-node MPI job in week 8" surprise while there is still time to plan for it.

Students authenticate with the same institutional identity they already use — SAML/Shibboleth or campus SSO — via the OOD reverse proxy (mod_auth_openidc or mod_shib). No separate classroom credentials, no password resets during week one.

Authorization is where classroom differs from research. Create a per-course Unix group, map it to a Slurm account, and use it for OOD app ACLs. Roster sync is the piece most centers underinvest in: pull from the SIS or LMS roster API and reconcile nightly during add/drop, so a student who drops on Tuesday is not consuming reserved cycles on Wednesday. For guest access (auditors, cross-registered students, K-12 outreach), issue short-lived accounts scoped to the course group with an explicit expiration date. FERPA-relevant course data should live under group-owned paths with tight ACLs and be excluded from center-wide backups unless retention is required.

The scenario to plan for is 180 students clicking "Launch Jupyter" at 2:59pm on the first Wednesday. Plan for simultaneous first-time logins, not just compute load — first-time account creation is CPU-intensive. Provisioning accounts before the first class meeting prevents this class of outage.

Three levers, in order of impact.

Reservations and partitions. Carve out a classroom partition (or reservation) sized to your peak concurrent-session estimate — typically 60–80% of enrollment for scheduled class meetings, 100%+ for the 24 hours before major deadlines. Make it preemptible-into by research jobs outside class hours so cycles are not wasted.

Right-sized defaults. Ship each classroom app with a small default resource request (1–2 cores, 4–8 GB, 2-hour walltime) and let students opt into larger requests only when the assignment requires it. Most intro courses will never touch the ceiling; overprovisioning by default is where classroom deployments blow their budget or unnecessarily tie up resources.

Session limits and staged launches. Set per-user concurrent-session limits (usually 1–2) and per-course caps so a runaway script from one student can not starve the class. For the first meeting, ask instructors to stage the initial launch — half the class starts at 3:00, half at 3:03 — which flattens the login and scheduler-request spike enough to matter. Watch queue depth and active-session counts in real time (Grafana against Slurm and OOD metrics is a common setup) so you can catch a pile-up while it is still recoverable.

A research app becomes a classroom app when a stranger at another institution can pick it up, adapt it to their course, and run it at scale without emailing you. Everything below is about closing that gap.

Test at classroom load before you tag it "classroom-tested." Run it at the concurrent-session count you expect from a real course — 50, 100, 200 — not just a one-user smoke test. Watch for licensing lockouts, scratch-space contention, and startup times that balloon under parallel launches. If it has not been through that, it is a research app that happens to be pinned in the dashboard.

Freeze and version the environment. Ship a specific Apptainer/Singularity image or a locked conda environment, not "install whatever is current." Include a changelog when you update. Instructors who built a syllabus around v1.2 will feel it when a student hits v1.4 mid-semester.

Sensible defaults sized for teaching. Default resource request should fit a typical intro-course session, not the largest job the app can run. Students opt into more; instructors do not spend the first week untangling why every session is queuing for a full node.

Document what an adopter needs, not what you built. Include OS and scheduler assumptions, GPU vs. CPU variants, module or container dependencies, and any license quirks. Add a short instructor-facing "how to adapt this to your course" note and a student-facing quickstart (five minutes, screenshots, no HPC jargon). The instructor note is the piece most contributions skip and it is the piece that drives reuse.

Tag it properly in the catalog. Subject area, course level, expected concurrent-session ceiling, license class, GPU requirement, and whether it has been used in production somewhere. The tags are how other centers find your work.

Contribute fixes upstream. If you started from an app from another institution and improved it, send the improvements back rather than forking silently. The catalog gets better when patches flow both directions.

This group is for discussion and sharing of tips and best practices for using Open OnDemand in the classroom. Share educational use cases, successes and challenges, OOD apps for classroom use, tips for supporting instructors, and more. Ask questions to others supporting OOD as an educational technology.

The goal is straightforward — create a community around the use of Open OnDemand in classroom settings. If you are spinning up a classroom deployment for the first time, or you have been running one for years and want to compare notes, this is where the conversation happens. Sys admins, instructors, and center staff are all welcome; there is no prerequisite beyond an interest in teaching on OOD.

The group meets the first Tuesday of every month at 2:00 PM ET.

Join and see past discussions

Let us know if we can include a story from you — your experience will benefit the community. Email Karen Tomko.

Stories do not need to be polished. A paragraph or two is plenty — just answer a few questions: what course and how many students, how you set things up, one thing that went better than expected, and one thing you would do differently. Numbers help when you have them, but a clear account without hard data is still valuable.

Stories written by both the instructor and the technical staff tend to be the strongest, because they show how the two sides coordinated. Photos and screenshots are welcome if your institution allows it.