Skip to main content

​
Organizations and permissions

Customer clusters belong to organizations. You can belong to more than one organization, and a cluster can also be shared with you through a Kubernetes resource grant. Every request is made as you; organizations have no credentials of their own. Your role in an organization, owner, admin, or member, and the permissions granted to you there decide what you can do on its clusters. An organization permission applies to every cluster it owns. A Kubernetes resource grant names one cluster or namespace and can be given to someone outside the organization. Slurm SSH access still requires organization membership and the organization’s SSH permission. See Permissions. Your SSH keys and login-shell preference belong to you and apply on every cluster where you have SSH access. Your Slurm username belongs to your membership: each organization gives you one for its clusters, and it becomes frozen when first included in an access list.

​
Two views of one cluster

Each cluster appears in both APIs, under the same cluster ID: To find a cluster and connect to it, you mostly use Platform. Access is decided in Business.

​
Inside a Slurm cluster

Every cluster runs Kubernetes. Most also run Slurm on top of it, which the API calls sunk. A Slurm cluster has these parts:
  • SSH gateway. The single SSH endpoint for many clusters. It reads the cluster ID from your login name and runs your session on that cluster’s login node. It supports shells, commands, SFTP, and forwarding to loopback ports on the login node. See Connect over SSH.
  • Login node. Where you land. You edit files and submit jobs here, and the jobs run on compute nodes. Depending on the cluster’s login mode, everyone shares one login node or each person gets their own.
  • Slurm controller. Queues jobs and starts them on compute nodes. You never log in to it.
  • Compute nodes. One per machine, each with 8 GPUs. Slurm groups them into partitions: all, which holds every node, and one per GPU type, such as compute-h200.
  • Shared storage. /home and /shared, mounted on the login and compute nodes, so a file you write on the login node is there when your job runs. Ceph or NFS can provide it. A cluster without shared storage gives each node its own /home. See Files and storage.
A cluster that runs only Kubernetes has none of these Slurm parts. You reach it with kubectl.

​
How access reaches a cluster

Access is decided in Business and applied by each cluster. A change goes through four steps:
  1. Someone changes access. A member registers or revokes an SSH key or changes their login shell, or an admin grants or removes clusters.ssh or clusters.ssh.admin.
  2. Business writes a new version of the access list for each affected cluster: every member who holds clusters.ssh, with their username, their keys, their login shell, and their access mode.
  3. The cluster applies the new list. Key and shell changes reach the gateway without restarts. Adding or removing a login account restarts nodes and ends running jobs; see Access changes restart nodes.
  4. Once the login nodes and Slurm controller have your access, GET /clusters/{clusterId}/ssh-access returns ready: true, provided you have an active key. Compute nodes and Slurm accounting can take longer; see Wait for access.
GET /organizations/{orgID}/clusters/{clusterID}/access shows the current list and whether the cluster has applied it.

​
Glossary