6.9 KiB
Вопросы к Sol — обсуждение MVP
Файлы для контекста (прочитай перед ответом)
/home/naeel/nubes/autotest/app-autotest/site/routes/api_test.py— текущий 9-шаговый CREATE + non-CREATE/home/naeel/nubes/autotest/app-autotest/site/routes/api.py— legacy эндпоинты (предлагаешь удалить)/home/naeel/nubes/autotest/app-autotest/site/runner.py— legacy runner (предлагаешь удалить)/home/naeel/nubes/autotest/app-autotest/site/config.yaml— предлагаешь удалить/home/naeel/nubes/autotest/app-autotest/site/db/init_db.py— схема БД/home/naeel/nubes/autotest/app-autotest/site/db/save_run.py— INSERT в runs/home/naeel/nubes/autotest/app-autotest/site/static/app.js— фронтенд/home/naeel/nubes/autotest/app-autotest/site/api/http_client.py— HTTP-клиент/home/naeel/nubes/autotest/app-autotest/site/api/auth.py— токены/home/naeel/nubes/autotest/app-autotest/site/app.py— точка входа, blueprint'ы/home/naeel/nubes/autotest/app-autotest/DOCS/gpt56-sol-plan.md— твой план
executor
Q1: Зачем выносить executor из /home/naeel/nubes/autotest/app-autotest/site/routes/api_test.py прямо сейчас?
Сейчас 9-шаговая логика CREATE и non-CREATE живёт в api_test.py:173-250 (функция api_test() + _send_params_terraform() + _normalize_value() + _resolve_ref_svc()). Вынос в отдельный operation_executor.py — рефакторинг с риском сломать CREATE. Почему не обернуть вызов существующего api_test из runner, а вынос сделать фазой 2?
Q2: executor внутри того же gunicorn-воркера или отдельный процесс?
Сценарий PostgreSQL — 10-20 минут. Redis — 3 минуты. Блокирует ли executor gunicorn-воркера на всё это время? Или запускать в threading.Thread как сейчас делает api_test?
YAML
Q3: Параметры — символьный code или numeric ID?
Предлагаешь code: {code: cpu, value: "500"}. Это читаемо, но требует резолва через /instanceOperations/default/{opId} → найти svcOperationCfsParamId для кода cpu. Числовой ID {104: "500"} работает сразу, но нечитаемо. Что предлагаешь для MVP?
Q4: lifecycle persistent — как найти «тот самый» instance?
По displayName == "autotest-postgres-permanent" через GET /instances? А если кто-то переименовал в UI облака? А если два сценария случайно создали инстансы с одинаковым именем?
Q5: cleanup always — что чистить если create упал?
Если POST /instances вернул ошибку — instanceUid пустой. Вызывать POST /instanceOperations {operation: "delete"} не на чем. Что удалять?
CMDB DELETE
Q6: Почему удалить CMDB DELETE из /home/naeel/nubes/autotest/app-autotest/site/routes/api_test.py?
Сейчас строка 217-222: CMDB DELETE для not-created инстансов. Nubes API (POST /instanceOperations {operation: "delete"} + /run) возвращает 422 «Отсутствует state» для not-created. Без CMDB у пользователя нет способа удалить битые инстансы кроме ручного UI облака. Может оставить но с логом, а не удалять?
БД
Q7: Зачем три таблицы (scenario_runs + scenario_steps + новые колонки в runs)?
Почему не две (scenario_runs + scenario_steps) и не менять существующую runs? Каждый шаг сценария уже вызывает save_run() из /home/naeel/nubes/autotest/app-autotest/site/db/save_run.py, который пишет в runs. Можно добавить scenario_run_id в runs без новой таблицы scenario_steps.
Q8: heartbeat — через БД? UPDATE каждые N секунд?
Не убьёт ли это PostgreSQL при частых сценариях? Альтернатива — файловый lock как в /home/naeel/nubes/autotest/app-autotest/site/operations/tracker.py (fcntl.flock).
UI
Q9: Вкладки — зачем?
Сейчас всё на одном экране (/home/naeel/nubes/autotest/app-autotest/site/templates/index.html). Добавление вкладок раздувает UI. Почему не добавить секцию «Сценарии» под списком инстансов, без переделки всего экрана?
Q10: Запрет innerHTML для error/log — почему?
Сейчас весь вывод идёт через _esc() (строка 263 app.js). Что конкретно не экранируется?
Prod policy
Q11: Почему такая сложная политика для MVP?
Проверка org UID, ClientID, allowlist delete, quarantine, purge_not_before — это не MVP. Почему не просто if stand == "prod": return {"error": "prod заблокирован для сценариев"} на первом этапе? Всё остальное можно добавить когда сценарии заработают на dev/test.
Legacy
Q12: /home/naeel/nubes/autotest/app-autotest/site/config.yaml — что в нём ценного?
Ты предлагаешь удалить. Но там могут быть настройки которые пригодятся. Что именно предлагаешь перенести в app.py?
Общие вопросы
Q13: Порядок шагов — почему удаление legacy (шаг 1) до создания executor (шаг 2)?
Если executor будет вызывать код из api_test.py, удаление api.py и runner.py безопасно делать первым — они не используются. Но config.yaml используется в runner.py:load_config(). Если удалить config.yaml до того как executor готов — не сломает ли это что-то?
Q14: Риски совместимости — ручной UI не сломается?
После всех изменений ручные операции в UI должны работать как раньше. Где самое узкое место? /home/naeel/nubes/autotest/app-autotest/site/routes/api_test.py:api_test() — основной обработчик, если его менять — риск для всего.