Skip to content

Latest commit

 

History

History
67 lines (49 loc) · 4.68 KB

TODO.md

File metadata and controls

67 lines (49 loc) · 4.68 KB

План реализации и заметки

сложные вопросы

Каждый элемент на своем уровне вложенности поэтому элементы одного типа могут и не совпадать по уровням.

Хотелось бы выровнять, но это приведет к усложнению алгортима. Из уровней формируется прямолинейный json. Этот json предполагается передавать между машинами чтобы не было обязательно устанавливать модуль или программу dot.

Что пытаемся нарисовать:

Граф рисуется слева направо (но тут элементы по типам записаны сверху вниз):

  • диски - disk
  • разделы - дисков part
  • md raid-устройства - mdraid (здесь снова могут быть разделы)
  • lvm-pv - lvm-pv
  • lvm-vg - lvm-vg
  • lvm-lv - lvm-lv (здесь снова могут быть разделы)
  • кеш lvm - (пропускаем в первой итерации программы )
  • файловые системы - fs
  • файловые системы loop игнорируются, потому что это монтирования proxmox - loopfs (однако, неплохо бы сделать вывод тех, которые по каким-то причинам не инвентаризовались в proxmox)
  • proxmox storage - px-storage
  • proxmox mountpoint и rootfs - px-mp
  • виртуалки proxmox. все вместе и CT и KVM - px vm

Таким образом, для каждого раздела по характерным меткам определяется его короткая символьная метка и формируются изобразительные свойства. Изобразительные свойства это title, description, status (ok|warn|fail) - фактически, это означает цвет нет цвета|желтый|красный

При формировании диаграммы перебираются возможные уровни и пропускаются полностью отсутствующие уровни. На каждом уровне выводятся элементы графа и выравнивающий элементы блок - {rank=same sda1 sdb1 sdc1 }

TODO

  • небольшие ошибки при работе с загрузкой inventory. Нужна защита и проверка наличия ключа в json. Пересобрать данные-примеры

  • изучение python autotests

  • изучение github actions

  • есть проблемы с не такими уж старыми proxmox.

  • сбор данных о pve-контейнерах

  • отрисовка pve-ресурсов

  • алгоритм меток переделать тк сущности разных типов могут перекрываться

  • debian 9 lsblk без параметра path ! алгоритм не может составить имя

  • сбор данных о dmraid

TODO пункты второй очереди

  • отображение конфигурации LVM. На самом ли деле нужны PV VG и LM? текущая реализация lsblk показывает корни и связи устройств можно и так понять используется ли VG или примонтировано сразу

  • сбор данных pvs --reportformat json

  • сбор данных vgs --reportformat json

  • сбор данных lvs --reportformat json

    • между прочим имена lv не обязательно уникальны. см. пример данных где LV lvvz создан два раза на VG raid1-md2 и VG vgprox
    • но они уникальный как комбинация
  • продумать как отображать сломанные и отсутсвующие в raid диски.они видны в /proc/mdadm, но их не будет видно в lsblk.

  • разные цвета для разных типов блоков. Светло-нейтральные.

  • обдумать использование других форматов - draw.io, dia, (ms visio ??)

  • ZFS. совершенно отдельный слой и отдельная обработка в proxmox.

  • кеш lvm

  • кеш bcache

  • кеш flashcache