188 lines
9.2 KiB
Markdown
188 lines
9.2 KiB
Markdown
# Backlog
|
||
|
||
## Сбор SFP-модулей
|
||
|
||
**Статус:** не реализовано.
|
||
|
||
### Источник данных
|
||
|
||
`ethtool -m <iface>` / `ethtool --module-info <iface>` — читает EEPROM SFP/SFP+/QSFP28/QSFP-DD по стандарту MSA (SFF-8472 / SFF-8636).
|
||
|
||
Доступные поля из EEPROM:
|
||
- Идентификатор модуля: `Identifier` (SFP, SFP+, QSFP28, …)
|
||
- Тип коннектора: `Connector`
|
||
- Вендор: `Vendor name`, `Vendor OUI`, `Vendor PN`, `Vendor SN`, `Vendor rev`
|
||
- Оптика: `Wavelength`, `Transceiver type` (10GBase-SR, LR, DAC, …)
|
||
- Телеметрия DOM (если модуль поддерживает): `Laser tx bias current`, `Transmit avg optical power`, `Receive avg optical power`, `Module temperature`, `Module voltage`
|
||
- Статус: `Rx power high alarm`, `Tx power low warning`, …
|
||
|
||
Для QSFP28 данные повторяются на 4 канала (lane 0–3).
|
||
|
||
Инструмент требует root. На bee ISO — доступен (`ethtool` входит в образ).
|
||
|
||
### Scope для bee
|
||
|
||
1. Собирать список сетевых интерфейсов через `ip -j link show` (только `ether`, без `lo`/VLAN/bond).
|
||
2. Для каждого интерфейса пробовать `ethtool -m <iface>`. Если модуль отсутствует или не поддерживает EEPROM read — тихо пропускать.
|
||
3. Связывать интерфейс с PCIe-устройством через `ethtool -i <iface>` → поле `bus-info` (BDF) → сопоставление с `pcie_devices[].slot`.
|
||
|
||
### Gap в контракте
|
||
|
||
Текущий контракт v2.10 имеет в `pcie_devices[]` скалярные поля:
|
||
- `sfp_temperature_c`, `sfp_tx_power_dbm`, `sfp_rx_power_dbm`, `sfp_voltage_v`, `sfp_bias_ma`
|
||
|
||
Этого **недостаточно**:
|
||
- Одна NIC-карта может иметь несколько портов — нужен массив, а не скаляр.
|
||
- Нет полей идентификации модуля (vendor, part_number, serial_number, wavelength, connector).
|
||
- Нет разбивки по каналам для QSFP28.
|
||
|
||
### Предлагаемое расширение контракта
|
||
|
||
Добавить в `pcie_devices[]` массив `sfp_modules[]`:
|
||
|
||
```json
|
||
"pcie_devices": [
|
||
{
|
||
"slot": "0000:3b:00.0",
|
||
"device_class": "EthernetController",
|
||
"model": "ConnectX-6 Dx",
|
||
"sfp_modules": [
|
||
{
|
||
"port": 0,
|
||
"identifier": "QSFP28",
|
||
"connector": "LC",
|
||
"vendor": "Mellanox",
|
||
"part_number": "MFA1A00-C003",
|
||
"serial_number": "MT2124VS09999",
|
||
"revision": "A",
|
||
"wavelength_nm": 850,
|
||
"transceiver_type": "100GBase-SR4",
|
||
"temperature_c": 36.4,
|
||
"voltage_v": 3.29,
|
||
"tx_power_dbm": -1.8,
|
||
"rx_power_dbm": -2.1,
|
||
"bias_ma": 7.2
|
||
}
|
||
]
|
||
}
|
||
]
|
||
```
|
||
|
||
Поля `sfp_modules[]`:
|
||
|
||
| Поле | Тип | Описание |
|
||
|---|---|---|
|
||
| `port` | int | Номер порта на NIC (0-based) |
|
||
| `identifier` | string | `SFP`, `SFP+`, `QSFP28`, `QSFP-DD`, … |
|
||
| `connector` | string | `LC`, `MPO`, `DAC`, … |
|
||
| `vendor` | string | Производитель модуля |
|
||
| `part_number` | string | Партномер |
|
||
| `serial_number` | string | Серийный номер |
|
||
| `revision` | string | Ревизия |
|
||
| `wavelength_nm` | int | Длина волны, нм |
|
||
| `transceiver_type` | string | `10GBase-SR`, `100GBase-SR4`, `DAC`, … |
|
||
| `temperature_c` | float | Температура модуля, °C |
|
||
| `voltage_v` | float | Напряжение, В |
|
||
| `tx_power_dbm` | float | TX оптическая мощность, dBm |
|
||
| `rx_power_dbm` | float | RX оптическая мощность, dBm |
|
||
| `bias_ma` | float | Bias current, мА |
|
||
|
||
Старые скалярные поля `sfp_temperature_c` / `sfp_tx_power_dbm` / `sfp_rx_power_dbm` / `sfp_voltage_v` / `sfp_bias_ma` на уровне `pcie_devices[]` — **вывести из контракта** (deprecated), заменить на `sfp_modules[]`.
|
||
|
||
### Порядок реализации
|
||
|
||
1. Согласовать расширение контракта с Reanimator Core (bump до v2.11).
|
||
2. Добавить `ethtool` parser в `audit/internal/collector/` — новый файл `sfp.go`.
|
||
3. Дополнить schema в `audit/internal/schema/` типом `SFPModule`.
|
||
4. Добавить `sfp_modules` в `PCIeDevice` в schema.
|
||
5. Заполнять в NIC-коллекторе: связь интерфейс → BDF → `pcie_devices[].sfp_modules`.
|
||
6. Показывать в TUI и web UI в разделе PCIe/NIC.
|
||
|
||
## BMC версия через IPMI
|
||
|
||
**Статус:** реализовано.
|
||
|
||
Добавить сбор версии BMC firmware в board collector:
|
||
- Команда: `ipmitool mc info` → поле `Firmware Revision`
|
||
- Записывать в `hardware.firmware[]` как `{device_name: "BMC", version: "..."}`
|
||
- Показывать в TUI правой колонке рядом с BIOS версией
|
||
- Graceful skip если `/dev/ipmi0` отсутствует (silent: same pattern as PSU collector)
|
||
|
||
## CPU acceptance test через stress-ng
|
||
|
||
**Статус:** реализовано. CPU в Health Check получает PASS/FAIL из summary.txt.
|
||
|
||
Добавить CPU SAT на базе `stress-ng`:
|
||
- Bake `stress-ng` в ISO (добавить в `bee.list.chroot`)
|
||
- Новый `bee sat cpu` — запускает `stress-ng --cpu 0 --cpu-method all --timeout <N>` где N = duration из режима (Quick=60s, Standard=300s, Express=900s)
|
||
- Параллельно снимает температуры через `sensors` и throttle-флаги из аудит JSON
|
||
- Результат: SAT архив с summary.txt в формате других SAT (overall_status=OK/FAILED)
|
||
- После реализации: CPU в Health Check получает реальный PASS/FAIL статус
|
||
|
||
## Real hardware validation
|
||
|
||
**Статус:** ожидает доступа к железу.
|
||
|
||
Что осталось подтвердить на практике:
|
||
- `bee sat nvidia` на реальном NVIDIA GPU host
|
||
- `bee sat storage` на NVMe/SATA/RAID host
|
||
- `ipmitool sdr` parsing на сервере с реальным BMC/IPMI
|
||
- vendor RAID tooling (`storcli64`, `sas2ircu`, `sas3ircu`, `arcconf`, `ssacli`) в живом ISO
|
||
|
||
## SAT result polish
|
||
|
||
**Статус:** частично закрыто.
|
||
|
||
Что ещё можно улучшить после полевой проверки:
|
||
- точнее классифицировать vendor-specific self-test outputs в `storage SAT`
|
||
- подобрать дефолты `memtester` по объёму RAM на целевых машинах
|
||
- при необходимости расширить `bee-gpu-stress` по длительности/нагрузке
|
||
|
||
## Hardware Contract backlog
|
||
|
||
**Статус:** уточнён, сокращён до `bee`-only snapshot scope.
|
||
|
||
### Не backlog для `bee`
|
||
|
||
Эти задачи не должны реализовываться в `bee`, потому что относятся к централизованному ingest/lifecycle слою:
|
||
- `status_history`
|
||
- `status_changed_at`
|
||
- определение замены компонента между snapshot'ами
|
||
- timeline/lifecycle/history по diff между экспортами
|
||
|
||
`bee` отвечает только за текущий snapshot железа и `status_checked_at`.
|
||
|
||
### Реализуемо инкрементально
|
||
|
||
Эти поля можно развивать дальше по мере появления реальных sample outputs и vendor-specific parser'ов:
|
||
- `cpus.correctable_error_count`
|
||
- `cpus.uncorrectable_error_count`
|
||
- `power_supplies.life_remaining_pct`
|
||
- `power_supplies.life_used_pct`
|
||
- `pcie_devices.battery_charge_pct`
|
||
- `pcie_devices.battery_health_pct`
|
||
- `pcie_devices.battery_temperature_c`
|
||
- `pcie_devices.battery_voltage_v`
|
||
- `pcie_devices.battery_replace_required`
|
||
|
||
### Vendor/platform-specific, часто пустые
|
||
|
||
Эти поля допустимо оставлять пустыми на части платформ даже после реализации parser'ов:
|
||
- `power_supplies.life_remaining_pct`
|
||
- `power_supplies.life_used_pct`
|
||
- часть `pcie_devices.battery_*` для неподдержанных RAID/NIC/GPU вендоров
|
||
|
||
### Unsupported в `bee`
|
||
|
||
Эти поля считаются нереалистичными для общего OS-level hardware snapshotter без synthetic/fake data:
|
||
- `cpus.life_remaining_pct`
|
||
- `cpus.life_used_pct`
|
||
- `memory.life_remaining_pct`
|
||
- `memory.life_used_pct`
|
||
- `memory.spare_blocks_remaining_pct`
|
||
- `memory.performance_degraded`
|
||
|
||
Причина: у обычного Linux-host audit обычно нет честного vendor-neutral runtime source для этих метрик.
|
||
|
||
Эти поля считаются дропнутыми из backlog `bee` и не должны возвращаться в план работ без появления нового доказуемого локального источника данных на целевых машинах.
|