Open OnDemand on

Overview

Tue, 15 Sep 2026 00:00:00 +0000

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.

Service Architecture

Tue, 15 Sep 2026 00:00:00 +0000

The Open OnDemand Service has three roles and uses two Virtual Networks. Each user session runs as a Slurm job on a pool of compute VMs that grows and shrinks.

Roles

Role	Cardinality	What it runs
`storage`	1	NFS server for the shared home directories, the state of the Slurm controller and the shared software directory. Squid cache for the EESSI catalogue, unless the service uses a proxy of the site
`portal`	1	Open OnDemand, its LDAP directory, Dex, the Slurm controller `slurmctld`, the accounting daemon `slurmdbd` with MariaDB, the Prometheus metrics exporter
`worker`	1 to 6, elastic	`slurmd`, joined to the cluster as a dynamic node, and the user sessions as Slurm jobs

OneFlow starts storage first. It starts portal when the storage role is ready, and worker when both are ready. Each role reports READY through OneGate only when it is actually serving. The service therefore reaches RUNNING when a user can sign in and open a session.

Quick Start

Tue, 15 Sep 2026 00:00:00 +0000

This guide deploys an Open OnDemand Service from the Sunstone Web UI, with one portal, one storage VM and one worker. Then it opens a JupyterLab notebook on the service. Check the Requirements first. You need OneFlow and OneGate enabled, and two Virtual Networks, one with Internet access and one reserved for the service.

Quick-start workflow:

Create the networks. A management network with Internet access, which you probably have, and a compute network reserved for the service.
Download the appliance. Import the image, the VM template and the service template from the Community Marketplace.
Instantiate the service. Select the two Virtual Networks and keep the default inputs.
Wait for the service. It reaches the RUNNING state in about four minutes.
Open the portal and launch a notebook. Sign in with the initial user and open JupyterLab as a Slurm job on the worker VM.

Before You Start

The service needs two Virtual Networks, and the wizard requests both:

Configuration

Tue, 15 Sep 2026 00:00:00 +0000

This section describes the inputs of the Open OnDemand Service. It also covers role sizing, the worker pool, worker sizes, its Slurm cluster, an external cluster, an external identity provider and user management.

Service Inputs

All inputs are ONEAPP_* context variables. OneFlow places every input in the context of every VM of the service, where root can read it. This includes ONEAPP_PORTAL_CERTIFICATE_KEY and ONEAPP_AUTH_OIDC_CLIENT_SECRET. Every input is optional, and the Sunstone wizard groups them in four tabs, Portal, Users and login, Home directories and Software catalogue. A feature with an _ENABLED switch shows its other inputs only while the switch is YES, and ignores them while it is NO. If a switch is YES and a required field is empty, the role stops at boot, and the message names the field, see A Role Does Not Reach RUNNING.

Operations

Tue, 15 Sep 2026 00:00:00 +0000

This section covers the lifecycle of a running Open OnDemand Service. It explains how to keep the home directories across deployments, upgrade the appliance, and remove the service.

Keeping the Home Directories

By default the shared home is on the root disk of the storage VM and is deleted with the service. Two options keep it.

A persistent disk on the storage role. Create a persistent Datablock and add it to the template_contents of the storage role in the service template. List it next to the disk of the appliance image, because a DISK entry there replaces the whole disk list of the VM template:

Monitoring and Troubleshooting

Tue, 15 Sep 2026 00:00:00 +0000

The Open OnDemand Service reports its state through OneFlow, OneGate and a Prometheus endpoint on the portal.

Metrics

The portal serves Prometheus metrics on port 9101 of its management address, at http://<portal management address>:9101/metrics:

Metric	Meaning
`ood_worker_active_sessions`	Slurm jobs running on the worker, sessions included (labels `vm_id`, `name`, `address`)
`ood_worker_idle_seconds`	Seconds since the last job on the worker ended
`ood_worker_oldest_idle`	`1` when the oldest worker of the role is drained and empty, so OneFlow may remove it
`ood_slurm_pending`	Jobs waiting for a worker of this role, as seen by the worker
`ood_slurm_idle_nodes`, `ood_slurm_alloc_nodes`	Idle nodes of the cluster, and nodes with a job, as seen by the worker
`ood_worker_healthy`	`1` when the worker passed its last check of the home mount, the software catalogue, munge and slurmd
`ood_role_cardinality`	VMs in each role
`ood_portal_puns`	Per user web servers running on the portal, one per signed in user
`ood_service_state`	The OneFlow state of the service, as its numeric code (`2` is RUNNING)
`ood_exporter_scrape_ok`	`1` when the exporter’s last read of the service through OneGate succeeded

The same values are in the user template of each worker VM, in Sunstone or in onevm show <worker id>. The template also holds SESSION_USERS, the users with a job on the worker. SLURM_NODENAME in the same template is the name of its Slurm node. A worker whose home mount, software catalogue, munge or slurmd fails publishes HEALTHY=0 until it recovers. On the portal, sinfo lists every worker as a node with its role as a feature. squeue lists the sessions and the batch jobs.