141 lines
9.1 KiB
Markdown
141 lines
9.1 KiB
Markdown
# Задача: универсальный генератор моков из STANDS YAML
|
||
|
||
## Контекст
|
||
|
||
**app-autotest** — тестирует сервисы Nubes. Для интеграционных тестов проектируется
|
||
**мок-полигон** — Flask-заглушка, притворяющаяся Nubes API.
|
||
|
||
Архитектура полигона уже спроектирована: см. `DOCS/polygon-plan.md`.
|
||
Ключевое решение: data-driven, сервисы описываются в YAML, эмулятор универсальный.
|
||
|
||
**Открытие:** в `STANDS/test/resources_yaml/` лежат 37 YAML-файлов, которые
|
||
генерит приложение для Terraform-провайдера. Эти YAML описывают ВСЕ сервисы
|
||
в универсальном формате — провайдер обрабатывает их без привязки к особенностям.
|
||
|
||
**Идея:** использовать эти YAML как источник для автоматической генерации
|
||
конфигов мок-полигона. Не писать YAML вручную — конвертировать из STANDS.
|
||
|
||
## Что прочитать Опусу (обязательно)
|
||
|
||
1. **`DOCS/polygon-plan.md`** — полный план полигона (369 строк)
|
||
2. **`STANDS/test/resources_yaml/1_dummy.yaml`** — Болванка (339 строк, простой)
|
||
3. **`STANDS/test/resources_yaml/90_postgres.yaml`** — PostgreSQL (934 строки, САМЫЙ сложный: 10+ операций, create_user/create_database, map-fixed с sub_params, resourceRealm)
|
||
4. **`STANDS/test/resources_yaml/150_k8s_sthutrval_cluster.yaml`** — K8s (371 строка, умеренно сложный)
|
||
5. **`STANDS/test/resources_yaml/115_mariadb.yaml`** — MariaDB (460 строк, похож на PG)
|
||
6. **`STANDS/test/resources_yaml/27_vc_vm_v2.yaml`** — VM v2 (71 строка, простой)
|
||
7. **`STANDS/test/resources_yaml/21_vc_vdc.yaml`** — vDC (169 строк, инфраструктурный)
|
||
|
||
**НЕ читать:** остальные DOCS, HISTORY, JS-файлы. Только polygon-plan и 6 YAML.
|
||
|
||
## Ключевой вопрос
|
||
|
||
Можно ли построить **универсальный конвертер** STANDS YAML → polygon-конфиг,
|
||
который работает для ВСЕХ 37 сервисов без сервис-специфичного кода?
|
||
|
||
Если да — спроектировать его архитектуру. Если нет — объяснить где проходит
|
||
граница универсальности и что придётся делать вручную.
|
||
|
||
## Что исследовать
|
||
|
||
### 1. Формат STANDS YAML — полнота и единообразие
|
||
|
||
Сравни 6 YAML-файлов (от простого dummy до сложного postgres). Ответь:
|
||
|
||
- Все ли поля, нужные полигону, присутствуют в STANDS YAML?
|
||
- Одинакова ли структура у всех 37 сервисов? Есть ли сервисы с нестандартной структурой?
|
||
- Покрывает ли STANDS YAML все типы параметров: string, integer, boolean, map, map-fixed, array, array(map)?
|
||
- Есть ли в STANDS YAML информация о valueList, refSvcId, dataDescriptor — или это нужно достраивать?
|
||
|
||
### 2. stateParams — генерация из create-операции
|
||
|
||
После create полигон должен отдавать `state.params` с ТЕКУЩИМИ значениями.
|
||
В STANDS YAML у create-операции есть `params[].default` — можно ли их использовать?
|
||
|
||
- Для всех ли сервисов create-операция имеет defaults для всех параметров?
|
||
- Как быть с параметрами без default? Брать из `default_for(dataType)`?
|
||
- Как мапятся `sub_params` (map-fixed) в state.params? Пример из postgres: `clusterConfiguration.replicas` → как это выглядит в state.params?
|
||
|
||
### 3. stateOut — генерация из операций
|
||
|
||
Для PostgreSQL `state.out = {users: {pgadmin: {}}, databases: {mydb: {}}}`.
|
||
|
||
В STANDS YAML у postgres есть операции `create_user` и `create_database`.
|
||
Можно ли по наличию таких операций автоматически сгенерировать структуру stateOut?
|
||
|
||
- У каких ещё сервисов есть `create_user`/`create_database`? (MariaDB, ClickHouse?)
|
||
- Есть ли другие паттерны stateOut кроме users/databases?
|
||
- Можно ли вывести правило: «если есть операция create_X → добавить X в stateOut»?
|
||
|
||
### 4. Маппинг полей 1:1
|
||
|
||
Составь таблицу маппинга STANDS YAML → polygon-конфиг для ВСЕХ полей.
|
||
Пример (начало):
|
||
|
||
| STANDS YAML | Polygon config |
|
||
|---|---|
|
||
| `service_id` | `serviceId` |
|
||
| `name` | `svc` |
|
||
| `operations[].id` | `svcOperationId` |
|
||
| `operations[].name` | `operation` |
|
||
| `params[].id` | `svcOperationCfsParamId` |
|
||
| `params[].code` | `svcOperationCfsParam` |
|
||
| `params[].data_type` | `dataType` |
|
||
| `params[].sub_params` | `dataDescriptor` |
|
||
|
||
Какие поля НЕ мапятся 1:1 и требуют трансформации?
|
||
|
||
### 5. Операции — какие включать
|
||
|
||
В STANDS YAML у postgres 10+ операций: create, delete, modify, suspend, resume,
|
||
restart, recovery, create_user, delete_user, create_database, delete_database.
|
||
|
||
Полигону нужны 6: create, modify, delete, suspend, resume, redeploy.
|
||
|
||
- У всех ли сервисов есть эти 6 операций?
|
||
- Что делать с «лишними» операциями (restart, recovery, create_user...)?
|
||
- Нужно ли их включать в мок? Если да — как они влияют на stateParams/stateOut?
|
||
|
||
### 6. resourceRealm и refSvcId
|
||
|
||
У многих сервисов есть параметр `resourceRealm` (ссылка на платформу k8s/vDC).
|
||
В полигоне refSvcId в MVP игнорируется (validate-cfs всегда OK).
|
||
|
||
- Достаточно ли просто принимать любое значение resourceRealm?
|
||
- Или нужно чтобы эмулятор возвращал реалистичный valueList для resourceRealm?
|
||
- Есть ли другие refSvcId-параметры кроме resourceRealm?
|
||
|
||
### 7. Краевые случаи
|
||
|
||
- Сервисы с `kind: user` или `kind: database` операциями — как их обрабатывать?
|
||
- Сервисы с `adopt_existing_on_create_default: true` — нужно ли эмулировать adopt?
|
||
- Есть ли сервисы где create-операция отсутствует (только modify/delete)?
|
||
- Параметры с `func: getAvailableResourceRealms` — динамический valueList, как эмулировать?
|
||
|
||
### 8. Архитектура конвертера
|
||
|
||
Если универсальный подход возможен — спроектировать модуль `polygon/from_stands.py`:
|
||
|
||
- Какие входы (путь к STANDS, фильтр сервисов)?
|
||
- Алгоритм конвертации одного YAML → polygon-конфиг
|
||
- Генерация stateParams (из create defaults + default_for)
|
||
- Генерация stateOut (из операций create_user/create_database)
|
||
- Обработка sub_params → dataDescriptor
|
||
- Что делать с полями которые не мапятся (man, descr, sort, func)?
|
||
- Выходной формат: один общий JSON/dict или отдельные YAML в `polygon/services/`?
|
||
|
||
## Ожидаемый ответ
|
||
|
||
1. **Вердикт:** возможен ли универсальный конвертер для всех 37 сервисов?
|
||
2. **Таблица маппинга:** все поля STANDS → polygon с пометками «1:1», «трансформация», «игнорировать»
|
||
3. **Алгоритм конвертации:** пошагово, с примерами для dummy и postgres
|
||
4. **Границы универсальности:** что НЕ покрывается автоматически и требует ручной доработки
|
||
5. **Архитектура from_stands.py:** структура модуля, функции, поток данных
|
||
6. **Изменения в polygon-plan.md:** что нужно поправить в существующем плане
|
||
|
||
## Ограничения
|
||
|
||
- Только Python (PyYAML для чтения STANDS)
|
||
- Результат — данные для MockState, НЕ код самого эмулятора
|
||
- Конвертер запускается один раз при старте полигона (или offline при сборке)
|
||
- Никаких внешних API, только чтение локальных YAML-файлов
|