Naming Conventions¶

All infrastructure devices follow a consistent naming scheme that encodes site, location, role, and instance number. The goal is to identify any device's site, physical location, and purpose from its hostname alone.

General Format¶

Rack-mounted devices:

{site}-{rack}-{role}{##}

Site-level devices (not tied to a specific rack):

{site}-{role}{##}

• site — short code identifying the physical site (see below)
• rack — rack or infrastructure location within the site
• role — abbreviated function (see table below)
• ## — two-digit instance number, zero-padded (01, 02, etc.)

Every device name starts with the site code. This avoids ambiguity when rack IDs like r01 or r02 exist at multiple sites.

Sites¶

A site is a physical location with its own network, power, and infrastructure.

Rack / Location Identifiers¶

Rack IDs are scoped per-site — r01 at Fairy is a different rack than r01 at Atlantis. The site prefix in the device name disambiguates.

Role Abbreviations¶

Cluster Names¶

Kubernetes clusters follow {site}-k8s{##}:

BMC / IPMI Names¶

Out-of-band management interfaces append -mgmt to the device name:

{device-name}-mgmt

Since the site is already encoded in the device name, no additional site suffix is needed.

Example: fairy-r02-cn01-mgmt for the BMC of fairy-r02-cn01.

Not all devices have built-in BMC/IPMI. The DGX Spark nodes (fairy-r02-dgx01 through fairy-r02-dgx03) use a JetKVM attached to each unit for out-of-band management. The -mgmt naming convention still applies — the JetKVM for fairy-r02-dgx01 is fairy-r02-dgx01-mgmt.

Examples¶