62 lines
4.9 KiB
Markdown
62 lines
4.9 KiB
Markdown
# Opus Questions + Answers — 2026-07-31
|
||
|
||
## A. Единый executor (operations/executor.py)
|
||
|
||
**A1. Граница executor: до /run включительно, без поллинга.**
|
||
Executor делает все шаги: POST /instances → POST /instanceOperations → send_params_terraform → /run. Возвращает `{instance_uid, op_uid, display_name}`. Поллинг — забота вызывающего (api_test.py: async thread, scenario.py: sync while).
|
||
|
||
**A2. Ошибки: dict `{ok, error, failed_step}`.**
|
||
Не исключения. `failed_step` = "instances" | "instanceOperations" | "params" | "run". Оба вызывающих конвертируют в свой формат (jsonify / RuntimeError).
|
||
|
||
**A3. Трекер: да, вызывать tracker_add внутри executor для всех create.**
|
||
Сценарные инстансы — такие же реальные инстансы в облаке, должны быть в трекере. Единообразие.
|
||
|
||
**A4. _finish_op: оставить в api_test.py.**
|
||
Но вынести цикл поллинга в общий хелпер `poll_until_done(client, op_uid, timeout=1800)` в `operations/poll.py`, который используют и _finish_op (async), и run_scenario (sync).
|
||
|
||
## B. Гибкие ссылки на инстансы
|
||
|
||
**B5. Приоритет: да. instance_uid > instance_ref > новый create.**
|
||
|
||
**B6. Хранение output→uid: и в памяти, и в БД.**
|
||
В памяти — словарь для быстрого резолвинга во время выполнения. В БД — `scenario_runs.instance_bindings` обновляется после каждого create-шага. При падении воркера видно что создалось. Но runner не зависит от БД для резолвинга (только память).
|
||
|
||
**B7. Валидация: да на всё.**
|
||
`_validate_steps()` проверяет: (a) instance_ref ссылается на output из предыдущих шагов, (b) output уникален в пределах сценария, (c) для не-create шага обязателен один из instance_ref/instance_uid.
|
||
|
||
**B8. Обратная совместимость: поддерживать оба формата, без миграции.**
|
||
Если шаг без output/instance_ref/instance_uid → fallback на старый instance_map[service_id]. Seed dummy_test работает как есть. Новые сценарии используют новый формат.
|
||
|
||
## C. Схема БД
|
||
|
||
**C9. Да, без изменений схемы.** Только новые опциональные ключи в JSONB-объектах шагов.
|
||
|
||
**C10. Да, использовать instance_bindings.** После create: `bindings[output_name] = instance_uid`. Сохранять в БД после каждого шага.
|
||
|
||
## D. UI редактора сценариев
|
||
|
||
**D11. Модальное окно на весь экран.** Параметры с dataDescriptor (map-fixed) — много вложенных полей, inline в scenario-body слишком тесно.
|
||
|
||
**D12. Да, вынести рендер параметров в общий модуль.**
|
||
`static/js/params-render.js`: `renderParamRow()`, `renderMapFixedRow()`, `collectParams()`. Используется и в operations.js, и в scenario-form.js.
|
||
|
||
**D13. Pre-fill: авто при смене операции.** Показывать ВСЕ параметры с defaults, пользователь удаляет лишние или меняет значения. Кнопка «Сбросить на defaults».
|
||
|
||
**D14. Символические имена в БД.** `{"durationMs": "5000"}` — человекочитаемо, стабильно. Резолвинг в numeric ID — в runtime.
|
||
|
||
## E. Оптимизация
|
||
|
||
**E15. Да, вынести в `api/utils.py`.** Обе реализации (_find_uid, _uid_from_location) унифицировать.
|
||
|
||
**E16. Да, startup check.** При старте: `UPDATE scenario_runs SET status='TIMEOUT', error_log='worker restart' WHERE status='RUNNING' AND created_at < NOW() - INTERVAL '1 hour'`. Просто, без доп. инфраструктуры.
|
||
|
||
**E17. Оставить lock_check.** Один сценарий за раз — безопасно. Можно ослабить позже.
|
||
|
||
**E18. Не в scope.** fallback на API работает, потеря stages — minor. Отдельная задача.
|
||
|
||
**E19. Порядок: бэкенд → UI.**
|
||
1. `operations/executor.py` + `operations/poll.py` + `api/utils.py`
|
||
2. Формат шагов (output/instance_ref) + валидация + резолвинг
|
||
3. Минимальные правки api_test.py и scenario.py (вызов executor)
|
||
4. UI редактор (модал + общий рендер параметров)
|