Features and the Database

The live cluster views only need slurmrestd. Everything else is optional and turns on when what it needs is configured. This page lists what each feature needs, which ones use a PostgreSQL database, and how to see what's on.

How Features Turn On

Since 3.0 you don't set a flag for each feature. A feature turns on by itself when its requirements are configured, and setting its flag to "false" turns it off.

GPU utilization and the AI assistant are the exceptions. They depend on services the dashboard can't detect, so they also need their flag set to "true".

Settings are read when the server starts. After you change one, restart the dashboard; you don't need to rebuild. The only build-time setting is NEXT_PUBLIC_BASE_PATH.

What Works With and Without a Database

Feature Flags

Each flag only turns its feature off. Leave it unset to let the feature turn on from what's configured.

Setting Up the Database

Rewind, node history, GPU history and job metrics use PostgreSQL 13 or newer. Create a database and a user that owns it, so the dashboard can create its tables:

CREATE USER slurmdash WITH PASSWORD 'change-me';
CREATE DATABASE slurmdash OWNER slurmdash;

Then point the dashboard at it in .env:

# Format: postgresql://username:password@hostname:port/database
DATABASE_URL="postgresql://slurmdash:change-me@db-host:5432/slurmdash"

Before 3.0 this setting was called SLURM_JOB_METRICS_DATABASE_URL. The old name still works.

Tables the Dashboard Creates

On startup the dashboard creates the tables it writes: dashboard_schema_migrations, node_events, node_state_time, node_snapshots, cluster_capacity, and organizations, account_mappings and job_gpu_metrics if they're missing. You don't run any migrations by hand.

Its database user needs CREATE permission on the database for that first start. If it doesn't have it, job metrics keep working, and Rewind snapshots and node history stay off until you grant it:

GRANT CREATE ON SCHEMA public TO <dashboard user>;

Job metrics also need slurm-history-ingestor writing job history to the same database.

Background Collection

With a database configured, the dashboard collects history itself. These replace the cron jobs from earlier versions.

If you run several dashboard instances against one database, only one of them collects at a time. The others take over if it stops.

Checking What's On

Open Admin → Plugins. It lists every optional feature in two groups, Without a database and With a database. Each feature shows whether it's on, the flag that controls it (if it has one), and a reason. When a feature is off, the reason says what's missing, for example:

• Set DATABASE_URL to turn this on.
• No job history yet. Run slurm-history-ingestor against this database.
• Turned off with NEXT_PUBLIC_ENABLE_HISTORY_PLUGIN=false.

The With a database group also shows the database's state: not configured, unreachable, connected with tables missing, or connected with the tables it found.