Полный код-ревью и вопрос: CREATE пропускает required-параметры

Что такое autotest

Flask 3.0 + gunicorn + vanilla JS. Тестирует Nubes REST API — создаёт/удаляет инстансы облачных сервисов (Redis, PostgreSQL, S3, etc.). Всё через API: POST /instances, POST /instanceOperations, POST /instanceOperationCfsParams, POST /run.

Текущий CREATE-флоу (код)

Файл: /home/naeel/nubes/autotest/app-autotest/site/routes/api_test.py, функция api_test(), строки 209-225:

display_name = _unique_display_name(client, display_name)
descr = f"created by autotest v{current_app.config.get('VERSION', '')}"
payload = {"serviceId": svc_id, "displayName": display_name, "descr": descr}
resp = client.post("/instances", payload)                    # шаг 1
instance_uid = resp.get("instanceUid") or _find_uid(resp) ...

op_payload = {"instanceUid": instance_uid, "operation": "create"}
op_resp = client.post("/instanceOperations", op_payload)     # шаг 2
op_uid = _find_uid(op_resp) ...

tracker_add(...)

for pid, pval in params.items():                             # шаг 3 — ТОЛЬКО пользовательские
    client.post("/instanceOperationCfsParams",
        {"instanceOperationUid": op_uid, "svcOperationCfsParamId": int(pid), "paramValue": str(pval)})
client.post(f"/instanceOperations/{op_uid}/run")             # шаг 4

Эталонный флоу (Terraform-провайдер)

Файл: /home/naeel/nubes/autotest/DOCS/terraform-operations-full-logic.md (скопирован из репы tf_provider)

Шаг 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)  ⬅ НЕТ В AUTOTEST
Шаг 7: GET /instanceOperations/{opUid}/validate-cfs
Шаг 8: POST /instanceOperations/{opUid}/run {}
Шаг 9: поллинг dtFinish

Баг

PostgreSQL (сервис 90, create opId=19) имеет 8 map-fixed параметров, все required:

startupConfiguration (id=789)
clusterConfiguration (id=788)
accessConfiguration (id=790)
postgresConfiguration (id=791)
postgresConf (id=792) — array-map-fixed
backupConfiguration (id=793)
autoscaleConfiguration (id=794)
mtlsConfiguration (id=1094)

Пользователь в UI заполняет первые 3-4. Остальные 4-5 не отправляются → Nubes возвращает: «Не передан параметр: serviceInstanceUid».

Redis (3 параметра), Болванка (все заполняются) — работают.

Нужное решение

Добавить шаг 6 в CREATE-ветку: после отправки пользовательских params, дослать required-параметры с их defaultValue, которые не были в пользовательском вводе.

Вопросы

Где брать список required-параметров с defaultValue?
- Вариант А: сделать GET /instanceOperations/default/{svcOperationId} (тот же что для /api/params) — там есть все params с isRequired и defaultValue. Взять те, где isRequired=True и svcOperationCfsParamId нет в params.keys().
- Вариант Б: сделать GET /instanceOperations/{opUid}?fields=cfsParams как Terraform (шаг 3) — после создания операции, получить cfsParams от сервера. Но это доп. запрос.
- Какой правильнее?
Как отличить «пользователь заполнил» от «не заполнил»? Сейчас params приходят из фронтенда как {"788": "{\"cpu\":\"500\",...}"}. Если поле не в params.keys() — значит юзер не заполнил. Но что если юзер оставил пустую строку? Достаточно проверки pid not in params или нужно проверять значение?
Нужны ли шаги 3 (GET cfsParams) и 7 (validate)? Terraform их делает. Без validate-cfs мы пропускаем серверную валидацию до /run. Это критично или нет?
Не сломает ли это существующие сервисы? Если добавить досылку required+default для ВСЕХ сервисов — не навредит ли это Redis/Болванке где и так всё работает?

5.0 KiB Raw Blame History Unescape Escape