# Дополнительные вопросы к Opus 4.8 > **Контекст:** ты уже проанализировал проект (3006_0.md). Ниже — уточняющие вопросы на основе новых данных, полученных после твоего анализа. Всё в режиме Plan — только чтение файлов, никаких правок. --- ## Вопрос 1: Расхождение версий — откуда 5.0.55? Ты отметил что кодовая база содержит версии 5.0.51 (universal_rebuild/main.go) и 5.0.52 (main.go Legacy). Но **регистр terra.k8c.ru отдаёт 93 версии до 5.0.55**. **Задача:** прочитай `devops/profiles/prod/profile.env`, `devops/profiles/test/profile.env`, `devops/03_build_and_upload_provider.sh`. Проверь — откуда брались версии 5.0.53, 5.0.54, 5.0.55? Это ручные билды? Или автоматические из CI? Где в коде хранится текущая версия universal-провайдера (кроме main.go)? Связанный вопрос: `HISTORY/OPUS/3006_0.md` — твой анализ — какая версия в нём указана? Соответствует ли она версии на регистре? --- ## Вопрос 2: Полный аудит фильтрации isDeleted Ты верно заметил что `FindInstanceByDisplayName` починен в 5.0.50, но **все ли** функции, обращающиеся к `/instances`, фильтруют deleted? **Задача:** прочитай `universal_rebuild/internal/core/refsvc_resolve.go` и `universal_rebuild/internal/core/client.go`. Составь полный список ВСЕХ функций, которые делают GET-запросы к `/instances` (любым способом). Для каждой проверь: 1. Есть ли `isDeleted=false` в URL 2. Есть ли проверка `isDeleted` в коде после ответа 3. Если нет ни того ни другого — это потенциальный баг класса #21/22/23 Особое внимание функции `findInstanceUidByDisplayNameRefSvc` — ты её упомянул в анализе. Проверь её сигнатуру и тело. --- ## Вопрос 3: Gitea 413 — проблема с пушем Мы сегодня обнаружили что `git push` на `gitea-naeel.giteak8s.services.ngcloud.ru` падает с HTTP 413 (nginx `client_max_body_size` = 1 MB). Даже пакет в 2 MB режется. **Задача:** проверь в репозитории: - `charts/` — есть ли там Helm-чарт для Gitea? Где конфигурируется nginx? - `k8s/` — есть ли манифесты Gitea с ingress/nginx аннотациями? - `.github/` — есть ли CI-пайплайны, которые деплоят Gitea? - `devops/ci/` — конфигурация CI Можно ли увеличить `client_max_body_size` через существующие манифесты/чарты в репо? Или это внешняя конфигурация? --- ## Вопрос 4: Suspend-способные сервисы — полный список Твой анализ упоминает что `hasSuspend` определяет `suspendOnDestroyDefault`. Но какие именно сервисы поддерживают suspend? **Задача:** прочитай `universal_rebuild/resources_yaml/embed.go` и все YAML-файлы в `universal_rebuild/resources_yaml/` (или в `devops/profiles/prod/generated/resources_yaml/` если есть). Составь: 1. Полный список сервисов, у которых есть операция `kind: instance, action: suspend` 2. Полный список сервисов, у которых есть операция `kind: instance, action: resume` 3. Есть ли сервисы, где suspend есть, а resume нет (или наоборот)? Это баг? 4. Для каждого suspend-способного сервиса проверь: совпадает ли `suspend_on_destroy_default` в YAML с тем что вычисляется в `service_spec_gen` (hasSuspend → true)? --- ## Вопрос 5: Terraform Operator — состояние и health Мы сегодня проверили кластер `iot-naeel` (через ВМ 5.172.178.213). В namespace `terra` три deployment'а: - `registry-server` — Running 81d - `terraform-operator` — Running 2d (перезапускался!) - `cloud-dashboard` — Running 74d **Задача:** прочитай в репозитории: - `k8s/` — манифесты для registry-server и operator'а - `charts/` — Helm-чарты если есть - `operator/` — код оператора - `registry-server-build/` — код registry-сервера Ответь: 1. Почему `terraform-operator` перезапустился 2 дня назад (30 июня), а остальные 81 день? Он крашился? 2. Достаточно ли трёх deployment'ов для полноценного registry? Не хватает ли docs-server'а (судя по `devops/04_build_and_publish_docs.sh`)? 3. Где хранятся GPG-ключи для подписи в кластере? Как operator получает доступ к S3? 4. Есть ли в репо конфигурация S3-бакета для хранения артефактов? --- ## Вопрос 6: Тестовые стенды — что реально используется? В репозитории есть: - `TEST_STAND/` — LUCEE, MARIA_DB, POSTGRES, S3_EVENT_FUNCTION_POC - `PROD_STAND/` — PG1, POSTGRES, RABBIT - `RABBIT/` — отдельный тест RabbitMQ **Задача:** прочитай `*.tf` файлы в этих директориях и определи: 1. Какие стенды реально используются (судя по датам файлов и содержимому)? 2. Какой провайдер используется — Legacy (`registry.terraform.io/nubes/nubes`) или Universal (`terra.k8c.ru/nubes/nubes`)? 3. Есть ли расхождения между стендами (разные версии провайдера, разные подходы)? 4. `TEST_STAND/POSTGRES/` — не дублирует ли он `PROD_STAND/POSTGRES/`? --- ## Вопрос 7: auth.k8s.ngcloud.ru — как работает аутентификация? Для доступа к кластеру мы используем токен от `auth.k8s.ngcloud.ru` (Keycloak realm `shturval`). **Задача:** найди в репозитории любые упоминания `auth.k8s.ngcloud.ru`, `keycloak`, `shturval`. Есть ли: 1. Конфигурация OIDC для кластера? 2. Скрипты обновления токена? 3. Инструкции по получению kubeconfig? 4. Связанные HAR-файлы (`HAR/keycloak.nubes.ru.har`)? --- ## Вопрос 8: Неиспользуемые PVC и orphan-ресурсы в кластере Мы нашли в кластере `iot-naeel`: - `default/storage-check-local` (100Mi) — тестовый PVC без пода - `default/storage-check-vcd` (10Gi) — тестовый PVC без пода - `509145c3-.../postgresqlk8s` — statefulset 0/0 уже 28 дней, но сервисы и PVC висят - `dc5db45d-.../postgresqlk8s` — statefulset 0/0 уже 28 дней, но сервисы и PVC висят **Задача:** проверь в репозитории: - Есть ли Terraform-конфиги, создававшие эти PVC (`storage-check-*`)? - Есть ли в `docs/` или `HISTORY/` упоминания о проблемах с PostgreSQL в этих тенантах? - Может ли `terraform-operator` быть причиной появления `storage-check-*` PVC (тестовые ресурсы оператора)? --- ## Формат ответа На каждый вопрос: **находка → файлы (конкретные строки) → вывод → рекомендация**. Если вопрос нельзя решить только чтением файлов репозитория — так и напиши, что нужно посмотреть за пределами репо (на кластере, в API).