Очередь установки: файлы, поля и ловушки

1. Зачем очередь и кто её читает

install-ng.py запускается с --config .../queue/<NODE>/config-ng.ini. config-ng.ini указывает на каталог (model_data_path), а остальные файлы этого каталога импортируются в модель: environment.json — окружение, network.json — сети, machine.json — машина, column.json — колонка, configrule.json — правила конфигурации. Плюс пара сертификатов и authorized_keys.

Восемь логических единиц (пара ca_cert.crt + ca_cert.key считается одной):

Набор в разных сборках может отличаться на один файл: ориентир — очередь с рабочего узла той же версии, а не список из документации.

2. config-ng.ini

Минимум, который проверяется всегда:

[general]
model_data_path = /opt/ampli/apps/marvinbase/queue/<NODE>
nr_of_nodes    = 0
policy_type    = single-denali-8

• model_data_path — абсолютный путь до каталога очереди, не относительный.
• nr_of_nodes = 0 отключает ожидание второго узла (wait_for_remote_pxe_nodes). Ставите один узел и не ждёте второй — ставьте 0; иначе установщик будет ждать партнёра.
• policy_type — ветка политики DSS под фактическое число блоксторов (single-denali-4/8/10/16/20/24). Стоковая ветка рассчитана на большие полки; для малого числа дисков её w+s не влезает, подробнее — Формула политики DSS.

Отдельная секция — привязка интерфейсов к сетям модели:

[spxctrlstoragemgmt_nic_network_map]
enp3s0   = <PUBLIC_NET>
enp5s0f1 = <PRIVATE_NET>

Имя секции — <роль машины в нижнем регистре>_nic_network_map. Без этой секции mgmt-адрес на ноду не приедет, хотя модель будет выглядеть зелёной. Если в логе есть строка no nic mapping entry for role ... — читать её буквально: секция названа не по той роли.

3. environment.json, network.json, location.json

• environment.json: новый deployment_id (у каждой инсталляции свой), name, domain, при необходимости additional_packages (например, пакет с профилем железа).
• network.json: PUBLIC и PRIVATE сети с подсетями. Приватная сеть обязательна — без неё install-ng не найдёт storage-сеть и упадёт на импорте.
• location.json: локация/стойка. Обычно переносится как есть; серийник локации в модели нужен, иначе GUI может показать пустую страницу «Ресурсы».

⚠️ Шлюз задаётся в модели (network.route или nic.gateway), а не руками на ноде: продукт рендерит сетевые конфиги из модели и перезапишет ручной ip route. Пустые route/gateway — это отсутствие default route: ноды видны в своих подсетях, из внешней сети — нет.

4. machine.json

• role — одна из допустимых ролей продукта. Для 3-нодного кластера — SPXCTRLSTORAGEMGMT (см. Роли нод).
• ipmi — полная вендорская форма: логин, секрет, address, netmask, dhcp, gateway, macaddress. Усечённый ipmi (только address) валится на 'Ipmi' object has no attribute 'id'.
• nic — только два реально работающих порта: mgmt и storage, адреса по MAC. Лишние порты из шасси в очередь не попадают: продукт пометит их NOTMANAGED, это нормально.
• bootmode — PXE для установки по сети. При bootmode=DISK установщик вообще не заходит в ветку osinstall и молча пропускает установку ОС.
• nictype — ether, не ethernet.
• имя сети в NIC — имя сети из модели (<PUBLIC_NET> / <PRIVATE_NET>), иначе Network PUBLIC not found.

5. column.json

• column_deployment_id = deployment_id из environment.json. Расхождение — колонка не привяжется.
• поля status быть не должно. Лишний status даёт column NOTINITIALIZED и валит установку.
• эндпоинты: S3/AXM — http://<STORAGE_IP>:11000-3 и http://<STORAGE_IP>:10000-3, Model API — https://<MGMT_IP>:8443/model/.

6. Ловушки, которые стоят прогона

1. Поле status в column.json → column NOTINITIALIZED.
2. Чужие MAC в machine.json → в модели появляются фантомные машины (PM-<mac>), и установка уходит не туда.
3. Лишний NIC с «своим» адресом → модель ждёт его в сети, нода навсегда остаётся в CONFIGURING.
4. authorized_keys из 15 байт (заглушка) → ключ не сработает, вход на узел только паролем.
5. nr_of_nodes не выставлен → установщик ждёт второй узел, которого нет.
6. Бэкапы .orig/.bak в group_vars → ansible грузит все файлы каталога, бэкап побеждает; правка «не применяется». Бэкапы выносить вне каталога продукта.
7. Импорт не обновляет существующую сеть: если сеть уже создана с другим диапазоном, адрес ноды даст IP address ... not part of referenced network. Сеть правится в модели, а не в очереди.

7. Проверка очереди до запуска (read-only)

1. jq . /opt/ampli/apps/marvinbase/queue/<NODE>/machine.json → валидный JSON, role из списка, ровно два NIC.
2. jq . .../column.json → column_deployment_id совпадает с deployment_id, поля status нет.
3. grep -E 'model_data_path|nr_of_nodes|policy_type' .../config-ng.ini → абсолютный путь, 0, существующая ветка политики.
4. wc -c .../authorized_keys → ключ, а не заглушка в несколько байт.
5. python3 -m json.tool по каждому JSON → без ошибок (битый JSON = отказ импорта).
6. Валидатор модели (install-ng.py -V) → model data validation successful, без incorrect value ... for role.

Только после этого — запуск. Порядок фаз и маркер завершения — install-ng: фазы и флаги.

8. Источники

• Software Documentation Center (дата доступа 2026-11-07)
• Наша практика (обезличено): подготовка очереди и прогоны install-ng на 3-нодных стендах.
• Обновлено: 2026-11-07.