⚠️ LEGACY — НЕАКТУАЛЬНО. Исторический документ.

Архитектура app-autotest — ответы Sonnet + моё мнение

Sonnet предложил

Q1: Модель данных — SQLite, четыре таблицы, YAML-seed при старте

Q2: Pipeline — последовательный в threading.Thread, поллинг 10s, таймаут 5мин

Q3: UI — три вкладки (Тесты, Конфигурация, История)

Q4: Архитектура — Flask + blueprints, sqlite3, без очередей/WS

Q5: Multi-stand — отдельный деплой на стенд, env vars

Мои замечания

⛔ 1. Factory pattern (`create_app()`) — НЕ СОВМЕСТИМ с pythonk8s

Sonnet предлагает app/ с фабрикой. ЭТО НЕ РАБОТАЕТ.

Nubes pythonk8s запускает python site/app.py. Папка site/ не может быть пакетом (конфликт с stdlib site.py). __init__.py в site/ ломает импорты.

Правильная структура для Nubes:

site/                    ← НЕ пакет, без __init__.py
├── app.py               ← точка входа: app = Flask(__name__)
├── api/
│   └── client.py        ← from api.client import ...
├── db.py
├── runner.py
├── yaml_loader.py
├── routes/
│   ├── config.py
│   └── history.py
├── static/
└── templates/

Все импорты — без префикса site., например: from api.client import HttpClient.

⚠️ 2. SQLite + Persistent Volume

pythonk8s на Nubes — есть ли persistent volume? Если нет — данные теряются при редеплое. Варианты:

/tmp/ — теряется при рестарте пода
Встроить SQLite внутрь? Но тогда это read-only FS
Использовать env var для пути БД

Нужно проверить: монтирует ли pythonk8s какие-то persistent тома.

⚠️ 3. threading.Thread + Flask debug=True

Сейчас debug=True (как в шаблоне). С reloader'ом (watchdog) треды могут дублироваться. В проде debug=False, но gunicorn workers тоже создают проблемы с тредами. Лучше:

Отдельный процесс (subprocess) вместо треда
Или threading только при debug=False

⚠️ 4. YAML-файлы — где брать?

YAML лежат в основном репо: /home/naeel/nubes/autotest/STANDS/, а не в app-autotest. Нужно:

Либо скопировать в app-autotest
Либо сделать git submodule
Либо mount volume с конфигами

Вопросы к Sonnet

Persistent storage: как хранить SQLite на pythonk8s? Есть ли volume mounts у этого типа сервиса?
YAML seeding: если YAML не меняются (seed только при первом старте), может проще держать их прямо в репо app-autotest? Обновлять при изменениях в STANDS/?
Threading: не лучше ли subprocess.Popen вместо threading.Thread для pipeline? gunicorn workers + debug reloader могут создать проблемы.
Параметры операций: в YAML есть dataDescriptor (подполя map-fixed) и valueList. Как их показывать в UI? JSON textarea для каждого параметра или динамическая форма?
Приоритет реализации: что первое — pipeline (запуск тестов) или конфигурация (UI настроек)? Без pipeline нечего тестировать, без конфигурации нечего запускать. Может MVP: ручной запуск + жёстко закодированный набор тестов?

4.1 KiB Raw Permalink Blame History Unescape Escape