Skip to content

Spec sheets

A spec sheet is a one-object PDF that reads like a vendor datasheet: the device, virtual machine or virtual chassis with everything Danbyte knows about it, laid out to be handed to an external party, a site technician, or a colleague who never opens Danbyte. Open the object and click Spec sheet - the PDF opens in a new tab, where the browser's viewer prints or saves it.

What is on the page

A4, built to print in black and white as well as colour:

  • Header - the name in bold, with role, site and rack position (or cluster for a VM) under it, the status pill, and the deployment name and generation time in the corner. The login logo uploaded under Settings → General is used when there is one.
  • Elevations - the device type's front and rear images as full-width strips right under the header, so the hardware is the first thing on the page. A virtual chassis shows every member's front, in position order.
  • Three stat boxes - the numbers wanted at a glance. Device: interfaces, power draw (the sum of its power ports' allocated or maximum draw), rack position. VM: vCPU, memory (in GB), total disk. Virtual chassis: members, interfaces, ports used.
  • Details - serial number, asset tag, type and part number, height, size, platform, primary and OOB IP, tenant, site, location, rack, cabinet (with rail and offset), cluster, virtual chassis, description, tags, and every custom field that has a value and is not hidden in its definition.
  • Port utilization (device and virtual chassis) - the same bar as the page: connected, reserved and free ports out of the counted total - physical interfaces and front ports, plus virtual interfaces when the deployment counts them (see What counts as a port). Left off when nothing is counted.
  • Modules and inventory (device), Storage (VM), or the member table (virtual chassis: position, device, master or member, priority, type, serial, status) followed by every member's front elevation in position order and each member's interfaces.
  • Interfaces - name, type, speed, MAC with its vendor, VLAN, IPs, and what the cable at the far end lands on. Sub-interfaces are indented; the dot in front of the name is filled when the port is enabled.
  • Comments - as written.
  • Images - the image attachments on the object, two per row with their captions, at the end.

Every page carries the object name, its Danbyte URL and the page count in the footer.

Changed in 0.17

The port figures - the Port utilization block and a virtual chassis's ports used box - count physical interfaces and front ports, plus virtual interfaces only when the deployment counts them. Until 0.17 they counted every interface and rear port, so a switch with many SVIs printed a lower fill.

The hardware sheet

A device has a second sheet, Spec sheet → Hardware sheet, for when the question is what is inside the box rather than where it sits. The header and elevations are the same; the three stat boxes become CPU (total cores, with sockets, clock and model underneath - or the socket count when no core figure is recorded), Memory (total size, with "2 × 64 GB · DDR4-2666") and Storage (total capacity, with the disk count, size and media). Then one table per kind - Processors, Memory, Storage, Other parts - each with the slot the part sits in (Socket 1, DIMM A1, Bay 3), its model, speed, cores or capacity, serial and status, followed by the modules. Rack position, power draw, port utilisation, interfaces and images are left off. The same totals sit above the parts table on the device's Hardware tab.

Memory always reads in GB: 32 sticks of 32 GB total 1024 GB, not "1.1 TB". A BMC sync (Redfish) records a DIMM in binary units and the part form in decimal ones; both show the same figure, "32 GB", whole when it is exact and to one decimal otherwise. Storage keeps the largest unit (1.92 TB).

Each table lists its parts by slot, then name, in natural order - DIMM 2 before DIMM 10, Bay 9 before Bay 10. Parts a BMC synced carry no slot, so their names order them. The modules and inventory list on the datasheet follow the same order.

All in one, the third entry, is the datasheet with the hardware block inserted: the three datasheet boxes, details, port utilisation, then the CPU, memory and storage boxes, the parts per kind, the modules, the interfaces, comments and images.

Endpoint

GET /api/devices/<id>/spec-sheet/, GET /api/virtual-machines/<id>/spec-sheet/ and GET /api/virtual-chassis/<id>/spec-sheet/ return application/pdf. The sheet is served inline; add ?download=1 for a download. The file is named <name>-spec-<serial>.pdf when the object has a serial number, else <name>-spec-<date>.pdf. On a device, ?variant=hardware returns the hardware sheet and ?variant=full the all-in-one sheet (<name>-spec-hardware-<serial>.pdf, <name>-spec-full-<serial>.pdf). Reading a sheet needs the same view permission as the object page, so site scoping applies unchanged.

The PDF is rendered server-side with the same engine as label templates, so it looks identical on every machine and needs no browser print dialog.

Roadmap

  • A logical topology drawing (the object's VLANs and L2 neighbours) below the interfaces.
  • Circuits as a third type - the handover sheet a provider or site tech asks for.
  • One merged PDF for a selection of devices.