Overview

The Open OnDemand Service deploys an Open OnDemand portal on OpenNebula. A user signs in from a browser and opens JupyterLab, RStudio, Octave, a C++ notebook, VS Code or an Xfce desktop on a compute VM. Scientific software comes from the EESSI catalogue, and the home directory is the same in every session.

The service is a OneFlow service built from one appliance image. Three roles boot from it, and every session is a job of the service’s own Slurm cluster. OneFlow adds a compute VM when a job waits for one, and removes the oldest worker once it has been idle. The service brings its own Slurm cluster and needs no other cluster. It suits teaching environments and notebook access for research groups.

How Should I Read this Chapter

Start with the Quick Start to deploy the service from the Community Marketplace and open a notebook. The Service Architecture explains the roles, the networks and how a session runs. Then:

  • Configuration covers inputs, scaling, worker sizes, Slurm, external identity providers and users.
  • Operations covers manual scaling, persistent home directories, upgrades and removal.
  • Monitoring and Troubleshooting covers metrics, logs, and what to check when something fails.

Usage Model in a Multi-Tenant Cloud

The service fits a cloud where several groups share one OpenNebula and each group works inside its own Virtual Data Center (VDC). Three actors take part, and only two of them need an OpenNebula account.

  • Infrastructure Admin. Runs the OpenNebula cloud and downloads the Open OnDemand Service from the Community Marketplace, which makes the image, the VM template and the service template available to every group. Also prepares what belongs to the site, which means the two Virtual Networks, the quotas of each VDC, the autoscaler_interval setting of the Front-end and, on a site with GPUs, the PCI passthrough configuration of the hosts.
  • Tenant Operator. Belongs to a group with a VDC. Instantiates the service from Sunstone inside that VDC and chooses the networks and the inputs. Creates the accounts of the end users in Open OnDemand, with ONEAPP_AUTH_LOCAL_USERS or through an OpenID Connect provider of the group. Watches the service, scales the worker role by hand when needed, and removes the service when the group no longer needs it. The VMs of the service count against the quotas of the VDC.
  • OnDemand End User. A researcher of the group. Signs in to the portal from a browser with the account the Tenant Operator created, opens JupyterLab, RStudio, VS Code or a desktop, and submits batch jobs. Does not need an OpenNebula account and never sees Sunstone. Every session runs as a Slurm job under that user, with the cores and the memory it requested.

The unit of isolation between groups is the Open OnDemand Service instance, not the portal inside it. One instance has one list of user accounts, one Slurm cluster and one shared home export, in which each user has a home directory of their own. Its users share the portal, the workers and the quotas, separated from each other only as Unix users and Slurm jobs. Two groups that must not share users, data or queue should run two instances of the service, each in its own VDC, and OpenNebula keeps them apart.

What the Service Manages

Every VM boots from the same image. ONEAPP_ROLE, set for each role in the service template, decides what the VM does:

  • storage. One VM. It exports the shared home directory, the state of the Slurm controller and the shared software directory over NFS, and caches the EESSI software catalogue.
  • portal. One VM. It runs Open OnDemand, the LDAP directory, the Dex login service, and the Slurm controller with its accounting database.
  • worker. One to six VMs, scaled by OneFlow. Each one joins the cluster as a Slurm node and runs the user sessions as jobs. Each job gets only the cores and the memory it requested.

The service also creates the initial users at first boot and keeps an accounting record of every session. It gives the portal a TLS certificate, which is self-signed by default. For a public name the certificate comes from Let’s Encrypt, or you can use one of your own.

Slurm Components

The service uses Slurm 23.11 as its job scheduler. A job is a request for cores, memory and time, together with the command to run. Every interactive session and every batch job from the Job Composer is a Slurm job. These are the components and where they run.

Component Runs on Function
slurmctld, the controller portal Keeps the list of nodes with their free cores and memory, keeps the job queue, and assigns each job to a node that has the requested resources. A job that fits on no node waits in the queue.
slurmd, the node daemon every worker Registers the worker as a node at boot, starts the jobs the controller assigns, as the requesting user, and limits each job to its cores and memory with cgroup v2.
slurmdbd and MariaDB, the accounting portal Record every job with its user, its node and its start and end times. sacct reads the record.
munge, the authentication every role Signs every message between the Slurm daemons and commands with a key shared by all the VMs of the service. A VM without the key cannot join the cluster or submit jobs. The portal generates the key at first boot and publishes it to the workers through OneGate.
OpenMPI and PMIx, multi-node jobs workers, from EESSI Let a batch job run processes on several workers at once. The job requests the nodes with sbatch -N <n> and starts the processes with srun --mpi=pmix or mpirun. Interactive sessions use one worker each.
  • OneFlow starts the roles in order and applies the elasticity policies of the worker role.
  • OneGate is the channel between the VMs and OpenNebula. Roles report readiness through it, and the portal publishes the cluster’s munge key. The workers publish the queue figures that OneFlow uses to scale. OneGate must be reachable from the service networks.
  • Open OnDemand is the portal software, from the Ohio Supercomputer Center. The service uses its slurm adapter for its own cluster and for an optional second Slurm Cluster.
  • Slurm is the workload manager, version 23.11 from Ubuntu 24.04. The portal runs the controller and the accounting daemon. Every worker joins as a dynamic node. Every session is a job, and cgroup v2 limits it to its cores and memory.
  • EESSI is a shared scientific software catalogue distributed over CernVM-FS. The image ships the CernVM-FS client and a site cache. The software itself is fetched on demand.
  • Elastic Slurm, the OneSlurm service, is optional. The Open OnDemand Service does not use it. A site that already runs one can attach it as a second cluster for batch jobs, with the same users and home directory, as described in Configuration.

Supported Versions

The appliance ships Open OnDemand 4.2 on Ubuntu 24.04 LTS, with Slurm 23.11.4, munge 0.5.15 and MariaDB 10.11 from the Ubuntu archive. It also ships EESSI 2025.06, Apptainer 1.5, TurboVNC 3.3 and Xfce 4.18. It runs on OpenNebula 6.10 and later with OneFlow and OneGate enabled. Open OnDemand is MIT licensed and the appliance code is Apache 2.0.