Приёмка после установки: 11 проверок с кодами и значениями

Коротко. Код возврата установщика ничего не доказывает: единственный надёжный признак завершения — маркер /tmp/.unattended_install_finished с кодом внутри, а «кластер работает» доказывается только живыми проверками. Ниже 11 проверок с ожидаемыми кодами и значениями: они закрывают федерацию, DSS, политику, S3, почту, железо и GUI. Приёмка — это протокол с выводом команд, а не «посмотрел, вроде зелёное».

1. Гейт перед приёмкой

Перед первой проверкой убедиться, что установка действительно закончилась:

cat /tmp/.unattended_install_finished     # exit code
pgrep -f "[i]nstall-ng.py"                # пусто = процесс завершился
tail -50 /opt/ampli/var/log/marvin/install.log

DONE_RC в выводе нет — не искать эту строку.
pgrep -f install-ng.py без скобок матчит вашу же команду и даёт ложное «жив».
Если процесс жив, приёмку не начинать: часть проверок увидит промежуточное состояние.

Фазы install-ng могут занимать часы. Приёмка имеет смысл только после маркера.

2. Проверки 1–4: федерация, DSS, неймспейсы, durability

#	Проверка	Как	Норма
1	Федерация жива	`curl -sk https://localhost:8443/federated/_status/`	`200` и < 50 мс
2	Барометр DSS	sherpa `cli.dss.capacity.read_barometer()`	`ok`
3	Неймспейсы заполнены	sherpa `cli.dss.capacity.get_namespaces_with_fill_status()`	все `status: ok`
4	Policy выбрана	`GET /model/environment/<ENV_GUID>/selectedstoragepolicy/`	не `null`

Разбор:

1. Время ответа важнее кода. 200 за 30 000 мс — это pymongo topology-hang: федерация/порт не тот, и дальше всё будет «медленным и странным». 404 — федерация не развёрнута (см. initialize).
2. barometer описывает, может ли DSS разложить экстенты. Не ok — политика не влезает в число блоксторов; смотреть проверку 5.
3. Пустой список неймспейсов или status не ok — данные писать некуда.
4. Если selectedstoragepolicy = null, GUI показывает пустые метрики Data Safety, хотя система здорова. Это не «сломанный GUI», а незаданная политика.

3. Проверки 5–7: политика и S3 round-trip

#	Проверка	Как	Норма
5	Политика влезает	sherpa `cli.dss.policy.list_all()`	`w + s ≤ N`
6	S3 пишет и читает	sherpa `cli.s3_connect('<ACCESS_KEY>')`, PUT/GET	round-trip совпал
7	Права аккаунта	PUT от пользователя (не администратора)	`200`

5. N — фактическое число блоксторов. Для 8 дисков рабочая ветка — 4/2, а не стоковая 13/4: стоковые политики рассчитаны на большие полки и в малое число дисков не влезают. Проверять надо и запас: политика, занимающая ровно N, при первом отказе диска остановит запись. Формула и ветки — Формула политики DSS.
6. Через sherpa удобно проверить S3 без установки клиента:

python conn = cli.s3_connect('<ACCESS_KEY>') b = conn.get_bucket('<BUCKET>', validate=False) b.new_key('probe.txt').set_contents_from_string('hello') print b.get_key('probe.txt').get_contents_as_string()

validate=False обязателен: TLS-сертификат продукта не проходит проверку по имени. - 7. PUT от обычного пользователя доказывает, что IAM и resource policy настроены, а не только что администратор может всё.

4. Проверки 8–11: почта, железо, GUI

#	Проверка	Как	Норма
8	Почта	`POST /model/location/<L>/connection/<c>/action/verify/`	`200`, задача `SUCCESS`
9	Вентиляторы	`GET /model/machine/<MACHINE>/fan/`	`NOTFOUND` пуст, число доков = физическим
10	NIC	`GET /model/machine/<MACHINE>/nic/`	ровно реальные порты, без дублей
11	GUI	`https://<MGMT_IP>:10443`	дашборд без пустых плиток

8. Действие называется verify/ (не verifyConnection), и вызывать его надо по scoped-URL (/model/location/.../connection/.../), иначе ответ — 307 и тело теряется. UI читает connections на уровне локации, поэтому документ должен лежать именно там.
9. NOTFOUND по вентиляторам — либо платформа не отдаёт датчики штатным типом IPMI, либо BMC отдаёт алиасы несуществующих вентиляторов. Лечится фильтром в профиле железа и повторным сканом; «пусто в NOTFOUND» — цель приёмки.
10. Дубли eth*/enp* означают, что в модели остались имена из шаблона. Число NIC должно совпадать с физическими портами; лишние порты продукт помечает NOTMANAGED — это норма.
11. Пустые плитки дашборда при зелёных проверках — обычно отсутствующий серийник локации или неполный профиль железа.

5. Как читать отказы

Что не так	Куда смотреть первым
п. 1 → `404`	stage-2 без федерации
п. 1 → десятки секунд	порт/репликасет федерации, `pgrep -af mongod`
п. 2 → не `ok`	политика против числа блоксторов
п. 4 → `null`	политика не выбрана в окружении
п. 5 → `w+s > N`	ветка `single-denali-*` не та
п. 6 → ошибка TLS	проверка имени сертификата, `validate=False`
п. 7 → `403`	нет resource policy у аккаунта
п. 8 → `307`	вызван не scoped-URL
п. 9/10 → мусор в модели	профиль железа, фильтры, повторный скан
всё зелёное, клиент не работает	сеть/DNS/TLS снаружи, не продукт

Последняя строка — важная: если по узлам всё ok, а клиент «не подключается», искать надо снаружи: какие порты проброшены, отвечает ли эндпоинт 443, резолвится ли bucket-стиль имени.

6. Протокол приёмки

Зафиксировать версию продукта и дату прогона в шапке протокола.
По каждой из 11 проверок вставить живой вывод (код, время, значение), а не «ок».
Отдельно записать, что осталось «не нормой» и почему (например, NOTFOUND по вентиляторам, которых физически нет).
Сохранить протокол вне узлов: после переустановки история нужна для сравнения.
Приёмку подписывает тот, кто видел вывод; пересказ чужих слов приёмкой не считается.

Приёмка — не формальность: она ловит то, что установка прошла с rc=0, а кластер при этом непродуктивен (пустая политика, отсутствие федерации, S3 без прав).

7. Источники

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

Приёмка после установки: 11 проверок