polygon/DEPLOYMENT_DIAGNOSIS.md

Диагностика: create прошёл, адрес Polygon не открывается

Дата инцидента: 25.10.2026

Наблюдения

• В интерфейсе создания показан ответ 201; в строке также указано время завершения 08:25:13.
• Браузер для https://polygon.pythonk8s.dev.nubes.ru/ сообщает DNS_PROBE_FINISHED_NXDOMAIN.
• NXDOMAIN означает, что DNS-имя не найдено. Браузер не дошёл до HTTP-запроса к Flask.
• Ответ 201 подтверждает ответ API на создание, но сам по себе не доказывает, что все стадии операции завершились успешно, под запущен и DNS-запись доступна.

Стадии и errorLog операции не приложены, поэтому точная причина по имеющимся данным не установлена.

Проверенные риски

Домен сервиса Nubes Flask

Источник схемы Flask — /home/naeel/TF/tf_provider/generated/<stand>/resources_yaml/89_flask.yaml. В accessConfiguration.domain короткое имя в одном октете предназначено для создания имени в служебной DNS-зоне. Для полного FQDN схема описывает проверку уже существующей A-записи, направленной на ingress.

Проверенный пример для DEV: domain = "flask-crud" даёт flask-crud.pythonk8s.dev.nubes.ru (/home/naeel/TF/tf_provider/stack/test/flask/facts.md). Поэтому следует сверить фактически отправленное значение domain и адрес state_out.connectionUrl. Если в create отправили полный FQDN, но A-запись заранее не существует, DNS-стадия может не пройти. Это гипотеза до просмотра стадий операции.

Относительный путь к YAML в Polygon

Ранее loader.py использовал пути относительно текущей рабочей директории: при запуске из корня репозитория это могло привести к поиску <repo>/services вместо <repo>/site/services и падению импорта до регистрации /health.

Исправление привязывает относительные значения по умолчанию и POLYGON_STANDS к каталогу site/, независимо от CWD. Регрессионные тесты импортируют полное Flask-приложение и проверяют /health с CWD корня репозитория и site/. Фактический CWD исторического деплоя и его логи не проверены, поэтому этот дефект не объявляется доказанной причиной инцидента.

Этот дефект мог помешать запуску приложения, но сам по себе не создаёт NXDOMAIN: DNS-имя проверяется до соединения с Flask.

Healthcheck

В app.py есть маршрут /health, возвращающий OK. Схема Nubes Flask разрешает пустой healthPath, при котором платформа проверяет доступность приложения по порту. Если в create указан непустой healthPath, нужно проверить, что это существующий маршрут и что под действительно слушает ожидаемый платформой порт.

Проверка гипотезы о старых YAML и задержке

config/loader.py перечисляет YAML только в каталогах, заданных POLYGON_STANDS, либо в services/ при отсутствии этой переменной. Каждый файл открывается и разбирается один раз при импорте config.loader; обработчики API затем используют загруженные словари из памяти. Резервные каталоги resources_yaml.bak-* из tf_provider Polygon не сканирует.

Следовательно, старый YAML может оставить устаревший сервис или параметры в ответах API и способен помешать запуску, если файл невалиден или отсутствует ожидаемый каталог. Генератор from_stands.py теперь удаляет YAML, отсутствующие в источнике, после полной успешной конвертации; если есть ошибки, очистка не выполняется. DEV, TEST и PROD копии были перегенерированы из текущих соответствующих каталогов tf_provider; fallback services/ — из DEV. Время загрузки YAML отдельно не измерялось, и нет основания связывать чтение старых файлов с DNS NXDOMAIN.

Исправление прежнего ответа: оценки размера и времени чтения YAML, а также предположение о конкретном negative-cache TTL DNS ранее были приведены без измерений и не являются установленными фактами. То, что адрес позднее открылся, доказывает только, что в момент повторной проверки он разрешался и отвечал; почему это изменилось, без DNS-диагностики и журналов Nubes неизвестно.

Удаление четырёх старых копий 27_vc_vm_v2.yaml не могло объяснить восстановление DNS: эти YAML влияют на содержимое API, а не на DNS-запись.

Что проверить для точного диагноза

1. В карточке инстанса: фактические startupConfiguration.resourceRealm, accessConfiguration.domain, appConfiguration.gitPath, appConfiguration.healthPath и state_out.connectionUrl.
2. У операции create: список stages, результат каждой стадии и errorLog, особенно стадии DNS и запуска приложения.
3. В логах пода: статус контейнера и traceback. Для старой опубликованной версии ошибка Services directory not found: services указывала бы на проблему CWD/YAML-пути.
4. В DNS: существует ли A-запись для точного state_out.connectionUrl и указывает ли она на ingress выбранного resource realm.

Вывод

Непосредственно DNS_PROBE_FINISHED_NXDOMAIN означает отсутствие разрешаемой DNS-записи для запрошенного имени. Наиболее важные проверки — сопоставить domain с state_out.connectionUrl и изучить DNS-стадию. Риск CWD/YAML-путей исправлен в коде и покрыт регрессионными тестами, но точная причина исторического инцидента остаётся неизвестной.

tf_provider — источник истины для схемы Flask; его YAML в рамках этого анализа не менялись.