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)

ЧТО НУЖНО НАЙТИ

ШАГ 3 Terraform vs наш код: Terraform делает GET /instanceOperations/{opUid}?fields=cfsParams ПОСЛЕ создания операции чтобы получить параметры С РЕЗОЛВОМ refSvcId. Мы берём из /instanceOperations/default/{svc_op_id} (шаблон). В чём разница? Может ли шаблон не содержать нужных значений которые появляются только в реальной операции?
ШАГ 4 Terraform vs наш код: resolveRefSvcParamValues — что это делает? Как Terraform резолвит refSvcId (например backupConfiguration.s3Uid ссылается на serviceId=12)? Есть ли у нас такой резолв?
ШАГ 6 Terraform vs наш код: Terraform досылает required+default. Мы тоже (v1.1.19). НО: Terraform берёт defaults из cfsParams РЕАЛЬНОЙ операции (шаг 3), а не из шаблона. Может ли быть расхождение?
ПОРЯДОК отправки params: В HAR, в каком порядке идут POST /instanceOperationCfsParams? Важен ли порядок?
serviceInstanceUid: Этого параметра НЕТ ни в YAML, ни в шаблоне API. Откуда он берётся? Может это внутренний параметр Nubes который появляется при резолве refSvcId?
ПРОВЕРЬ ВЕСЬ НАШ КОД на предмет любых других расхождений с 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

4.9 KiB Raw Blame History Unescape Escape