Commands reference
Global options precede the command group: rms [--base-url …] [--output json|table] [--profile …] [-v] [-q] <group> <command> …. Destructive commands (delete, cancel, remove, lifecycle transitions) prompt for confirmation unless you pass --yes / -y.
Create and update commands accept arbitrary model fields with repeatable -f key=value (values are coerced to bool/int/float/JSON where they parse):
rms pool create --name "GPU Pool" --org 1 -f queue_hold_seconds=120
auth
rms auth login --username you --password ••••••••
rms auth status
rms auth logout
org
rms org list [--name …] [--user <id>]
rms org get <org-id>
rms org create --name "Acme" [-f key=value …]
rms org update <org-id> [--name …] [-f key=value …]
rms org delete <org-id> [--yes]
rms org member list <org-id> [--user <id>]
rms org member add <org-id> --user <id> [--role …]
rms org member remove <org-id> <member-id> [--yes]
user
rms user list [--email …]
rms user get <user-id>
rms user create -f email=you@example.com -f name=You
rms user update <user-id> -f key=value
rms user delete <user-id> [--yes]
pool
rms pool list [--org <id>] [--name …] [--bookable]
rms pool get <pool-id>
rms pool create --name "GPU Pool" --org 1 [--bookable/--not-bookable] [--queue-hold-seconds 60]
rms pool delete <pool-id> [--yes]
# Booking rules (per-pool policy)
rms pool rule list <pool-id>
rms pool rule create <pool-id> -f key=value
rms pool rule delete <pool-id> <rule-id> [--yes]
resource
rms resource list --pool <id> [--name …] [--hostname …] [--bookable] [--state <int>]
rms resource get <resource-id> --pool <id>
rms resource create --pool <id> -f hostname=host-1 -f name=Host
rms resource delete <resource-id> --pool <id> [--yes]
# Capabilities (drive resource matching in booking queries)
rms resource capability list <resource-id> --pool <id> [--name …] [--type …]
rms resource capability create <resource-id> --pool <id> -f name=GPU -f type=NVIDIA
rms resource capability delete <resource-id> <capability-id> --pool <id> [--yes]
booking
A booking is a queue entry: you submit a resource-matching query (plus timing) against a pool and the backend matches a concrete resource, moving the entry PENDING → MATCHED → EXPIRED/CANCELLED. The query uses the resource service's advanced-search syntax (capability(name='GPU') AND state=READY).
rms booking validate --pool 12 --query "capability(name='GPU') AND state=READY"
rms booking create --pool 12 --query "capability(name='GPU')" --available-for 120 [--timeout 15] [--name "Nightly run"]
rms booking create --pool 12 --query "…" --start 2026-07-01T09:00:00Z --end 2026-07-01T11:00:00Z
rms booking list --pool 12 [--status <int>] [--resource <id>] [--user <id>]
rms booking get <booking-id> --pool 12
rms booking cancel <booking-id> --pool 12 [--yes]
# Notifications on a booking
rms booking notification list [--pool <id>] [--booking <id>]
rms booking notification create --booking <id> -f key=value
rms booking notification delete <notification-id> [--yes]
--start/--end and --available-for are mutually exclusive.
analytics
Read-only reporting.
rms analytics states [--pool <id>] [--resource <id>] [--timeframe 7days] [--grouping All]
rms analytics compare [--pool <id>] [--state <int>] [--sort-by percentage] [--sort-order desc]
--timeframe is one of all | 1day | 7days | 30days | 90days; --grouping is All | Working | Idle.
lcm
Lifecycle transitions operate on an event (a booking's lifecycle), so they take --pool, --event and --resource.
rms lcm begin <state> --pool <id> --event <id> --resource <id> [--event-status <int>] [--yes]
rms lcm end <state> --pool <id> --event <id> --resource <id> \
--transaction <id> --transaction-status <int> --event-status <int> [--yes]
rms lcm mark-ready --pool <id> --event <id> --resource <id>
rms lcm session start --pool <id> --event <id> --resource <id>
rms lcm session complete --pool <id> --event <id> --resource <id> \
--transaction <id> --transaction-status <int> --event-status <int>
<state> is one of ready | preparing | in_session | restoring | validating | error | maintenance | unavailable.