> ## Documentation Index > Fetch the complete documentation index at: https://docs.andromeda.ai/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Cluster API calls are made as a signed-in person with an OIDC bearer token. There are no API keys, and service-account tokens are refused (Business returns 401, Platform returns 403). > Platform takes the organization as the query parameter businessOrgId on most cluster routes, but as organizationId on /clusters/{clusterId}/ssh-access and /clusters/{clusterId}/kubeconfig. > The Business API uses snake_case. The Platform API uses camelCase, except /ssh-access and /machines, which use snake_case. > Business write requests need Idempotency-Key and Audit-Reason headers. > Storage capacity can grow but cannot shrink, including disk and PVC resizing. Each purchase adds capacity. > A cluster's storage can be Ceph, WEKA, or both, or NFS on its own. The Ceph quota, the purchased bytes, and Slurm's default 100 GiB shared-volume request are three different quantities. > Organization permissions cover every cluster the organization owns. A Kubernetes resource grant shares one cluster or namespace, possibly with someone outside the organization, and lets them read that cluster and fetch its kubeconfig. A grant does not give Slurm SSH, Slurm configuration, or organization storage inventory access. Slurm SSH requires organization membership and clusters.ssh. > The SSH login name is .. The gateway supports shells, commands, SFTP (including modern scp), and forwarding to loopback ports on the login node. Legacy scp and rsync need their programs on the login node. Remote forwarding and non-loopback destinations are refused. > Use POST /me/ssh-keys for personal key registration. POST /organizations/{orgID}/ssh-keys is a deprecated alias and requires no membership. Read the preferred shell from GET /me as user.login_shell; update it with PUT /me/login-preferences. > GET /clusters/{clusterId}/ssh-access returns 200 with ready and reason, even when access is not ready. ready: true does not mean compute nodes or Slurm accounting are ready. To confirm a key or shell change reached a cluster, require observation_current: true and compare ssh_key_set_generation with generation from GET /me/ssh-keys, and shell with user.login_shell from GET /me. > Adding or removing a login account restarts the cluster's login nodes, Slurm controller, and accounting service, then its compute nodes one at a time; jobs running on a restarting node end. An account is added or removed when a person with an active key gains or loses SSH access, or a person with SSH access registers their first key or revokes their last. Other key changes and shell changes restart no nodes. # Concepts > Organizations and permissions, the Business and Platform views of a cluster, the parts of a Slurm cluster, and how access changes reach it. ## 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](/clusters/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: | API | What it tells you | Reference | | - | - | - | | Business | Which reservation created the cluster, how many nodes it should have, and who can log in | [Clusters (Business)](/api-reference/business/clusters) | | Platform | Whether it is running, where, whether Slurm and storage are ready, and how to connect | [Clusters (Platform)](/api-reference/platform/clusters), [Cluster access](/api-reference/platform/access) | 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: ```text theme={null} ssh .@ | v +-------------+ | SSH gateway | one gateway serves many clusters +-------------+ | +----------------|------------------ cluster ----------------------------+ | v | | +------------+ sbatch, srun +------------------+ | | | login node | ---------------> | Slurm controller | | | +------------+ +------------------+ | | | | | | | v | | | +--------------+ +--------------+ | | | | compute node | | compute node | ... | | | | 8 GPUs | | 8 GPUs | | | | +--------------+ +--------------+ | | | | | | | ========+=====================+=================+======== | | shared storage: /home and /shared | | | +------------------------------------------------------------------------+ ``` * **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](/clusters/ssh#what-the-gateway-supports). * **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](/clusters/ssh#files-and-storage). A cluster that runs only Kubernetes has none of these Slurm parts. You reach it with [kubectl](/clusters/kubernetes). ## 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](/clusters/ssh#access-changes-restart-nodes). 4. Once the login nodes and Slurm controller have your access, [`GET /clusters/{clusterId}/ssh-access`](/api-reference/platform/access) returns `ready: true`, provided you have an active key. Compute nodes and Slurm accounting can take longer; see [Wait for access](/clusters/ssh#wait-for-access). [`GET /organizations/{orgID}/clusters/{clusterID}/access`](/api-reference/business/clusters#read-a-clusters-access) shows the current list and whether the cluster has applied it. ## Glossary | Term | Meaning | | - | - | | access list | The list of people who can log in to one cluster, with their usernames, keys, login shells, and access modes. | | cluster ID | A UUID that names a cluster in both APIs. It is also the first part of your SSH login name. | | login mode | `Shared`, where everyone uses one login node, or `PerUser`, where each person gets their own. | | organization username | Your login name on one organization's Slurm clusters. Chosen when you join and frozen when first included in an access list. | | partition | A named group of compute nodes that jobs are submitted to, such as `all` or `compute-h200`. | | SUNK | Slurm running on the cluster's Kubernetes. Appears in the API as the scheduler value `sunk`. | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.