docs: Sonnet — full Terraform diff analysis request

2026-07-29 12:49:10 +04:00
parent 32008463bc
commit ce19eff9de
1 changed files with 68 additions and 0 deletions
@@ -0,0 +1,68 @@
+# Sonnet 4.6 — СВЕРКА С ТЕРРАФОРМОМ: почему autotest не работает а Terraform работает
+
+## СУТЬ ПРОБЛЕМЫ
+
+Terraform-провайдер создаёт PostgreSQL БЕЗ ошибок. Autotest (наш код) — падает с «Не передан параметр: serviceInstanceUid». Мы скопировали «похожую» логику, но где-то расхождение. Нужно найти ВСЕ расхождения, пошагово.
+
+## ЭТАЛОН — Terraform CREATE flow
+
+Файл: /home/naeel/nubes/autotest/DOCS/terraform-operations-full-logic.md (читай ВЕСЬ, особенно строки 30-90)
+
+```
+Шаг 1: POST /instances                   {serviceId, displayName, descr}
+Шаг 2: POST /instanceOperations          {instanceUid, operation:"create"}
+Шаг 3: GET /instanceOperations/{opUid}?fields=cfsParams  ← получить ВСЕ params с defaults
+Шаг 4: resolveRefSvcParamValues          ← резолв refSvcId параметров
+Шаг 5: POST /instanceOperationCfsParams  ← пользовательские params (×N)
+Шаг 6: POST /instanceOperationCfsParams  ← required params с defaultValue, НЕ переданные в шаге 5 (×M)
+Шаг 7: GET /instanceOperations/{opUid}/validate-cfs
+Шаг 8: POST /instanceOperations/{opUid}/run {}
+Шаг 9: поллинг dtFinish
+```
+
+## НАШ КОД — CREATE flow
+
+Файл: /home/naeel/nubes/autotest/app-autotest/site/routes/api_test.py, функция api_test(), строки 170-245
+
+Прочитай ВЕСЬ файл, особенно:
+- Строки 170-195 — создание instance + operation
+- Строки 207-245 — отправка params + досылка required+default + validate + run
+
+## HAR-файл — реальные API-вызовы Terraform
+
+Файл: /home/naeel/nubes/autotest/development/dummycreate.har
+Это HAR с реальными запросами Terraform при создании Болванки (сервис 1).
+Найди ВСЕ POST /instanceOperationCfsParams — посмотри КАКИЕ именно params отправляются, в КАКОМ порядке, с КАКИМИ svcOperationCfsParamId.
+
+## PostgreSQL YAML — структура параметров
+
+Файл: /home/naeel/nubes/autotest/STANDS/dev/resources_yaml/90_postgres.yaml
+Читай строки с operations.create.params — там 8 map-fixed параметров с sub_params.
+
+Также проверь через API что реально возвращается:
+```
+curl -H "Authorization: Bearer <TOKEN>" /instanceOperations/default/19
+```
+(create opId для PostgreSQL = 19)
+
+## ЧТО НУЖНО НАЙТИ
+
+1. **ШАГ 3 Terraform vs наш код**: Terraform делает GET /instanceOperations/{opUid}?fields=cfsParams ПОСЛЕ создания операции чтобы получить параметры С РЕЗОЛВОМ refSvcId. Мы берём из /instanceOperations/default/{svc_op_id} (шаблон). В чём разница? Может ли шаблон не содержать нужных значений которые появляются только в реальной операции?
+
+2. **ШАГ 4 Terraform vs наш код**: resolveRefSvcParamValues — что это делает? Как Terraform резолвит refSvcId (например backupConfiguration.s3Uid ссылается на serviceId=12)? Есть ли у нас такой резолв?
+
+3. **ШАГ 6 Terraform vs наш код**: Terraform досылает required+default. Мы тоже (v1.1.19). НО: Terraform берёт defaults из cfsParams РЕАЛЬНОЙ операции (шаг 3), а не из шаблона. Может ли быть расхождение?
+
+4. **ПОРЯДОК отправки params**: В HAR, в каком порядке идут POST /instanceOperationCfsParams? Важен ли порядок?
+
+5. **serviceInstanceUid**: Этого параметра НЕТ ни в YAML, ни в шаблоне API. Откуда он берётся? Может это внутренний параметр Nubes который появляется при резолве refSvcId?
+
+6. **ПРОВЕРЬ ВЕСЬ НАШ КОД** на предмет любых других расхождений с Terraform flow. Не только CREATE — MODIFY, DELETE, SUSPEND, RESUME тоже.
+
+## Файлы для анализа (ВСЕ!)
+
+- /home/naeel/nubes/autotest/DOCS/terraform-operations-full-logic.md — эталонный flow
+- /home/naeel/nubes/autotest/development/dummycreate.har — реальные запросы
+- /home/naeel/nubes/autotest/STANDS/dev/resources_yaml/90_postgres.yaml — PG параметры
+- /home/naeel/nubes/autotest/app-autotest/site/routes/api_test.py — ВЕСЬ наш код CREATE
+- /home/naeel/nubes/autotest/app-autotest/site/operations/get_params.py — get_params_with_current_values