Release Cycle
Major versions of Slurm-web are published following a six months release cycle, with releases planned in May and November every years. All major versions include new major features. Intermediate minor versions can be released as needed to publish bug fixes and minor features.
Prioritization
Upcoming work is ordered by community votes on the backlog below. Each feature shows how many ballots it has received; the list is sorted so the most supported ideas rise to the top.
Become a Slurm-web sponsor to receive vote ballots on the roadmap. Sponsorships are tied to the product: choose a plan, then assign your ballots to the features that matter most to your organization—the more ballots a feature collects, the stronger its case for the next release.
Prefer to fund one item directly? Request a quote to order development of a specific feature, take part in shaping its specification, and align delivery with the release cycle.
Become a sponsor Become a sponsorBacklog
Features are listed by community votes. Cast your vote with a sponsorship, request a quote to fund a feature directly, or suggest a new idea.
Change node state, such as drain or resume, from the web interface, with dedicated permissions. Operators can take a node out of service or return it without a shell on the cluster, and users without that permission cannot alter node state.
Add an RBAC action so coordinators can view the jobs of the accounts they are responsible for, without opening every job on the cluster. Account managers can follow their users' workload from the web interface while jobs from other accounts stay hidden.
Show each user and account share, their usage, and the current fairshare factor, with help text in the interface. Users can see why their priority is what it is, and administrators can check that fairshare matches the configured policy.
Cancel, hold, and release jobs from the web interface, with each action protected by its own permission. Users can act on their jobs, and operators can intervene, without a Slurm command, while people without the permission cannot change job state.
Show the output of a job's processes on the job details page, and keep it updating while the job is running. Users can follow a running job from the browser instead of opening a session on the compute node to read the logs.
Let users submit batch jobs from the web interface using templates defined by the site's developers. People who do not work from the command line can launch a known workload, while the site keeps control of the scripts and of the parameters those templates expose.
Chart the resources actually consumed by the processes inside a job allocation. Users and support staff can compare that consumption with what the job requested, which helps explain a failure or a request that was larger than the work.
Present Slurm scheduling statistics, in the spirit of sdiag, in a readable layout with help text beside the figures. Administrators can judge scheduler health from the interface without memorizing what each counter means.
Show jobs on cluster resources in a Gantt chart that covers past, running, and future jobs. Users and operators can see how allocations line up over time and which resources are already reserved, without reconstructing the schedule from the command line.
Display the history of events recorded on a compute node, such as the node going down or being resumed. Operators can reconstruct what happened on that node and explain a state change without searching Slurm logs by hand.
Generate usage reports for the whole cluster and per association, over a day, a week, or a month. Site managers can see how capacity was consumed and which accounts used it, without exporting accounting data and building the same summaries themselves.
Provide a set of predefined widgets that can be arranged in a custom layout on the dashboard. Each team can put the cluster signals it cares about on the home page instead of working from one fixed view.
Push near real-time updates from Slurm to the browser with Server-Sent Events, so job and node changes appear as they happen. Users and operators no longer wait for the next refresh to notice a job start, a completion, or a node state change.
Give job arrays their own display so the tasks that belong to the same array can be browsed together. Users can move through a large array without treating every task as an unrelated job in the queue.
Build metrics and charts from completed jobs stored in an analytics database such as Elasticsearch, OpenSearch, or ClickHouse. Sites can follow completion trends beyond the live queue, using the database they already collect accounting data into.
Create, modify, and delete Slurm advanced reservations from the web interface. Operators can book a set of resources for a time window, then adjust or remove that reservation, without using the reservation commands.
Ship SELinux file labels in the packages, together with the policy changes Slurm-web needs. Sites that run with SELinux enforcing can install the components and have them start confined, without writing a local policy first.
Give heterogeneous jobs a dedicated display so each component can be opened from the set it belongs to. Users can see how the parts of one heterogeneous job are allocated instead of searching the queue for related job IDs.
Create, modify, and remove QOS definitions in the Slurm accounting service through forms in the interface. Administrators can adjust limits and settings without writing sacctmgr commands, and the form makes the available parameters easier to review.
Create, modify, and remove accounts and user associations, restricted by dedicated permissions. Accounting administrators can maintain who is allowed to run under which account from the browser, and people without that permission cannot change the associations.
Translate the web interface so it can be presented in languages other than the default. Users who do not work in that language can read job, node, and cluster information in a language they understand.
Render cluster resources as a 3D view in the browser with WebGL. Operators can look through a large machine the way it is laid out and spot idle, allocated, or failed equipment in a spatial view rather than a flat list.
Show the power consumption of jobs and nodes in the web interface. Sites can see which jobs and which nodes draw power, and follow that consumption alongside the work, without a separate energy dashboard.
Let sites choose the colors used for node states and for how those nodes are allocated. Racks and node views can follow an existing convention, so operators recognize a drained, down, or allocated node by the colors they already use.
Let users lower the priority of selected jobs by applying a nice factor. A user can let other jobs in the queue move ahead without cancelling work that can wait.
Explain a job's pending reason in full text instead of leaving only the short Slurm code. Users can tell whether they are waiting on priority, resources, a reservation, or a limit, and what that wait means, without decoding the reason string.
Show how many licenses are still available and which jobs hold the ones already allocated. Users waiting on a licensed application can see who is using the seats, and operators can tell a license shortage from a shortage of nodes.
Let users register for notifications of selected cluster events, in the same spirit as strigger. They can be told when a job or a node changes state without keeping a session open or polling the interface.
Keep an unprivileged view of the cluster open to anonymous visitors when authentication is enabled. Sites can publish a public overview and require a sign-in for jobs, accounts, and other sensitive views.
Let the LDAP client present its own certificate and private key on an ldaps:// connection, in addition to checking the server certificate. Sites that require mutual TLS, such as those using Google Workspace LDAP service , can sign users in with the directory they already run.
Cache Slurm responses in a Redis Cluster of several nodes, in addition to a single Redis server. The cache stays available when one node fails, so repeated views of the cluster no longer depend on a single instance.
Show sharded GPUs, the Slurm gres/shard resource, alongside the whole GPUs already listed and drawn. Users and operators can see how a shared GPU is divided, instead of finding no trace of that resource in the interface.
Download the jobs selected in the list as a CSV file that carries every field visible in that view. Users can open the file in a spreadsheet and compute the figures they need, without copying rows out of the interface by hand.
Add options to display columns to the jobs list for the submission time, the start time, and the walltime. Those times sit on the list itself, so users no longer open each job to see when it was submitted, when it started, or how long it may run.
Sign users in through PAM, using the accounts already defined on the host. Clusters that do not run an LDAP directory can still require a login, without keeping a password store that exists only for the interface.
Run Slurm-web on a cluster configured without a Slurm accounting service. Sites that keep only the live controller can browse jobs and nodes, without deploying slurmdbd for the views that do not need accounting data.
Ideas
Missing something on the list? Share a new idea—we review every proposal and may add it to the public backlog for others to vote on.
Suggest a featureDone
Add an RBAC action that limits a user to their own jobs. Sites can open the interface to a large community while keeping other people's jobs out of view.
Publish container images that run under Docker, Podman, or any other OCI runtime, including Kubernetes. Sites can deploy Slurm-web where RPM or deb packages are not available, including older distributions those packages do not cover.
Sign users in through an OpenID Connect or OAuth2 provider, with support for common providers such as Authentik and Keycloak. People use the same single sign-on as for their other services, instead of a password dedicated to Slurm-web.
Replace the default logo and colors with the site's own. The interface can carry the organization's visual identity, so users recognize it as an internal service.
List jobs completed over the past hours or days, with their return code, from the Slurm accounting service. Finished jobs remain visible after slurmctld has dropped them from the live queue, so users can still find a recent result.
Show each job's name in the list, and filter that list by name with a regular expression. Users can find a workflow by the name they gave it at submission instead of remembering the job ID.
Show users and the account tree with the parameters and limits defined on them. Administrators can review who belongs to which account and which limits apply, without dumping the associations from sacctmgr.
Serve the interface from a subdirectory of a web server that also hosts other applications, for example under /slurm-web/. Sites can publish Slurm-web beside existing services instead of dedicating a virtual host to it.
Reset the cache hit and miss counters from the cache settings. Administrators can start a clean measurement after a configuration change, instead of reading totals that mix several periods.
Draw how cores on a compute node are allocated to jobs. Operators can see whether jobs are packed together or fragmented across the node, which a single count of allocated CPUs does not show.
Print the node name on the rack drawing when there is enough room for the label. Users can identify a node on the picture without hovering for a tooltip, and the label is omitted where it would not fit.
Expose cache hit and miss statistics from the agent. Administrators can see whether Redis is absorbing repeated requests and how much load is still reaching Slurm.
List GPGPUs with their allocation and draw them on the rack view. Users can see which GPUs are free or in use, and operators can place GPU work on the drawing of the machine instead of reading GRES fields in command output.
Offer a dark color theme for the interface. Users who work for long sessions, or in a dark room, can lower the brightness of the dashboard.
Let the agent connect to slurmrestd over a TCP/IP socket as well as a Unix socket. Slurm-web can run on a host that does not have the local socket, which fits an agent separated from the controller.
Show a site-written message on the login page for production notices such as a maintenance window or an ongoing incident. Users read the status of the service before they sign in, instead of discovering the notice only after something fails.
Expose scheduling, job, and node metrics on an endpoint that Prometheus can scrape. Existing monitoring can alert on the cluster from the same place as the rest of the infrastructure, without scraping Slurm directly.
Chart high-level metrics such as node states and the depth of the job queue from an external time-series database. Operators can see how the cluster evolved over recent hours or days, not only the snapshot on screen. These charts use the metrics exported for Prometheus.
Mark completed jobs in the list with a visual indication of their exit code. Failures are visible in the queue itself, so users do not have to open every finished job to find the ones that did not succeed.
On the node details page, list the jobs currently running on that node. An operator looking at a busy or unhealthy node can see which jobs are placed there without cross-checking the queue.
Show the Slurm version running on each configured cluster. Support staff can see which release a cluster is on before they interpret a behavior or plan an upgrade, without logging into the controller.
Authenticate requests between Slurm-web components with JSON Web Tokens. The gateway and the agents can verify each other on every call, so access between components does not rely on an implicit trust of the network.
Authenticate users against an enterprise LDAP directory, including directories that follow the RFC 2307 bis schema such as FreeIPA, Active Directory, and OpenLDAP. People sign in with the account they already have, and the site does not keep a separate password store for the interface.
Control what each user can see and do through a role-based authorization policy. Administrators grant access by role instead of opening the whole interface to everyone who can log in.
Cache Slurm responses in the agent with Redis, so repeated views of the same data do not each trigger a new request. The interface stays responsive when many users browse the cluster, and the load on slurmrestd stays lower.
Deliver the interface as a reactive application built with Vue.js. Views update as data arrives, and moving between jobs, nodes, and clusters stays in the browser instead of reloading a full page for every action.
Open on a home dashboard with the main figures for the current state of the cluster. Operators get a first look at how the machine is running before they open the jobs or nodes views.
List the jobs known to Slurm and split that list into pages. Queues of more than a thousand jobs stay usable, because users can move through them without loading every job onto one page.
Sort the job list by ID, user, state, or priority, in either direction. Users can bring the jobs they are looking for to the top, for example the highest priority or one user's work, instead of scanning the default order.
Filter the queue by state, user, account, QOS, and partition. A user or an operator can restrict the list to one workflow, one account, or one partition and ignore the rest of the cluster.
Open a page with the full detail of a job, including allocated resources, the submit line, and the exit code, for running jobs and for jobs that have already finished. Users can see how a job was launched and how it ended without running scontrol or sacct.
List compute nodes with the partition they belong to and their current state in Slurm. Operators can scan the fleet from one page instead of reading sinfo output.
Filter the node list by state and by partition. Failed or down nodes stand out from the healthy ones, so an operator can focus on the partition that needs attention.
Give each node a page that gathers its operating system, its Slurm status, and its failure reason in a readable layout. Operators can see why a node is unavailable without collecting that information from several commands.
Draw compute nodes in their datacenter racks and show their Slurm status on that drawing. Operators can see where a down or allocated node physically sits, which is easier to act on than a hostname in a list.
List every QOS defined in Slurm with its settings and limits, and explain those fields in the interface. Users and administrators can read a limit without looking up the accounting documentation for each parameter.
List advanced reservations with their start, end, resources, users, accounts, and tags. Operators and users can see what is booked and for whom without querying the reservation commands.
Distribute Slurm-web as RPM and deb packages for the common Linux distributions. Administrators install and upgrade it with the same tools they use for the rest of the system, instead of deploying from source.
