Inspection data¶
The in-band inspection processes collects a lot of information about the node. This data consists of two parts:
- Inventory depends on the inspection interface used. See Inventory. 
- Plugin data is data populated by ramdisk-side and server-side plug-ins. See Plugin data. 
After a successful inspection, you can get both parts as JSON with:
$ baremetal node inventory save <NODE>
Use jq to filter the parts you need, e.g. only the inventory itself:
$ # System vendor information from the inventory
$ baremetal node inventory save <NODE> | jq .inventory.system_vendor
{
  "product_name": "KVM (9.2.0)",
  "serial_number": "",
  "manufacturer": "Red Hat",
  "firmware": {
    "vendor": "EDK II",
    "version": "edk2-20221207gitfff6d81270b5-7.el9",
    "build_date": "12/07/2022"
  }
}
$ # Interfaces used to create ports
$ baremetal node inventory save <NODE> | jq .plugin_data.valid_interfaces
{
  "eth0": {
    "name": "eth0",
    "mac_address": "52:54:00:5e:09:ff",
    "ipv4_address": "192.168.122.164",
    "ipv6_address": "fe80::5054:ff:fe5e:9ff",
    "has_carrier": true,
    "lldp": null,
    "vendor": "0x1af4",
    "product": "0x0001",
    "client_id": null,
    "biosdevname": null,
    "speed_mbps": null,
    "pxe_enabled": true
  }
}
Inventory¶
The shape of the inventory depends on the inspection interface used.
- agent - For information on what gets reported by this interface see hardware inventory. 
- redfish - This interface aspires to the agent implementation but is known to be incomplete at this time. 
Since many server-side plug-ins, known as Inspection hooks live in the Ironic source tree an effort is being made to define it here.
Top-Level¶
| Key | Details | 
|---|---|
| 
 | JSON object of CPU details | 
| 
 | JSON object of memory details | 
| 
 | Optional IPv4 address as a string | 
| 
 | Optional IPv6 address as a string | 
| 
 | List of JSON objects of disk details | 
| 
 | List of JSON objects of NIC details | 
| 
 | JSON object of SMBIOS details | 
| 
 | JSON object of boot details | 
| 
 | Optional JSON object of LLDP data | 
| 
 | Optional list of JSON objects of PCI details | 
| 
 | Optional list of JSON objects of USB details | 
Plugin data¶
Plugin data is the storage for all information that is collected or processed by various plugins. Its format is not a part of the API stability promise and may change depending on your configuration.
Plugin data comes from two sources:
- inspection collectors - ramdisk-side inspection plug-ins. 
- Inspection hooks - server-side inspection plug-ins. 
Data storage¶
There are several options to store the inspection data, specified via the
inventory.data_backend option:
- none
- Do not store inspection data at all. The API will always return 404 NOT FOUND. 
- database
- Store inspection data in a separate table in the main database. 
- swift
- Store inspection data in the Object Store service (swift) in the container specified by the - inventory.swift_data_containeroption.
Warning
There is currently no way to migrate data between backends. Changing the backend will remove access to existing data.
