tf_provider/docs/HAR_SNAT_MODIFY_FINDINGS.md

HAR-разбор: SNAT / ipSpace / модификации (dev)

Дата: 2026-09-22. Источник: /home/naeel/TF/tf_provider/HAR/*.har (записи UI на dev-стенде, 2026-09-20). Релевантные файлы: edge_.har (SNAT/Edge), ipSpace0.har, org_enough_.har, org_not_enough_.har, org0.har.

Поток modify в реальном API

1. POST /api/v1/svc/instanceOperations — {"instanceUid":"...","operation":"modify"} → возвращает instanceOperationUid.
2. POST /api/v1/svc/instanceOperationCfsParams — по одному запросу на параметр: {"paramValue":"...","instanceOperationUid":"...","svcOperationCfsParamId":NNN}.
3. GET /svc/instanceOperations/{id}/validate-cfs
4. POST /svc/instanceOperations/{id}/run
5. Поллинг GET /svc/instanceOperations/{id}.

Найденные payload-и

Операция	param id	код	значение из HAR
edge modify	368	needEnableAVI	false / true
edge modify	369	virtualServicesCount	1 / 2
edge modify	856	qosProfile	QoS-100Mbit
edge modify	372	ipSpaceName	no-needed / ""
edge modify	1112	routedNetConfiguration	{"mainDns":"81.22.46.22","secondDns":"185.247.187.77","ipAddrPool":"10.10.102.0/24"}
org modify	662	vIPConfigure	[{"name":"internet-ipv4-v1","count":"3"}]

Ответы на открытые вопросы

1. Тумблера «Выделить VIP для SNAT» в API НЕТ. SNAT управляется целиком через ipSpaceName (param 372). Его valueList (из метаданных в HAR): no-needed, internet-antiddos-v1, internet-no-antiddos-v1, ... — то есть no-needed это легальное значение «SNAT не нужен».
   • Включить SNAT: ipSpaceName = <имя ipSpace из org>.
   • Выключить: ipSpaceName = "no-needed".
2. ✅ Каноническое «SNAT выключен» = no-needed. Подтверждено: в UI (Edge → Modify → поле «ip Space для VIP», параметр ipSpaceName) текущее значение показывается как no-needed. Reverse для SNAT = modify с ipSpaceName="no-needed" → delete SNAT-модификатора можно реализовать не как no-op. ("" из ipSpace0.har — не каноническое, а промежуточное состояние.)
3. 🟡 Де-аллокация IP в org — попытка зафиксирована (org2.har, 2026-09-22): UI отправил modify с vIPConfigure=[{"name":"internet-ipv4-v1","count":"2"}] (count уменьшен с 3 до 2). HTTP-ошибки НЕТ, но операция осталась в isPending:true — не выполнилась (согласуется с ограничением ниже). Вывод: payload де-аллокации = ТА ЖЕ структура vIPConfigure, только меньше count (не отдельная операция). Точная семантика «удалить совсем» (count=0 или опустить элемент) не подтверждена. 🔴 Ограничение (подтверждено): уменьшить/удалить ipSpace в vcOrg нельзя, пока существуют дочерние инстансы (VDC/Edge/кластер). Следствие: reverse возможен только ПОСЛЕ уничтожения детей → порядок destroy критичен: кластер → SNAT-модификатор (no-needed) → org IP de-alloc → edge → vdc → org. Чтобы снять payload «удалить совсем», нужен чистый org без детей (или плановый teardown).

Побочные факты

• У ipSpaceName (372) в API есть valueList, но в нашем YAML его нет → проверить, тянет ли генератор valueList (возможно, он динамический: имена ipSpace конкретной org).
• Имя ipSpace в живом примере — internet-ipv4-v1 (не произвольное).
• qosProfile (856) UI всегда шлёт как QoS-100Mbit.
• routedNetConfiguration передаётся JSON-строкой.
• В состоянии org: "vip":{"no-needed":{},"internet-ipv4-v1":{"count":4}} — no-needed фигурирует и в стейте.

Наблюдения на возможно сломанном Edge (2026-09-22, nsx_WZ03709-saas-wmfop5be)

⚠️ ВАЖНО: этот Edge, судя по всему, в сломанном состоянии (devops-проблема). Ошибки ниже НЕ считать универсальными правилами API — перепроверить на здоровом Edge.

1. modify 14:40:52 → «ipSpace '' не найден на https://sandbox.nubes.ru» — при пустом ipSpaceName бэкенд отклонил запрос. ❓ Возможно, следствие сломанного Edge, не правило.
2. modify 14:43:44 → «Insufficient rule blocks» при попытке снять «Включить ALB». ❓ Возможно, застрявшие VS/SE Group, не правило.
3. delete (2 раза) → FORBIDDEN «Cannot delete SE Group assignment … since there are Virtual Services». ❓ Возможно, застрявшие VS, не правило.

Что остаётся надёжным (из API-метаданных, НЕ из этих ошибок):

• valueList у ipSpaceName содержит no-needed (+ имена ipSpace) — из описания параметра.
• UI показывает no-needed как текущее значение при выключенном SNAT.

Что ещё нужно выяснить из UI (открытые вопросы)

1. 🔴 Де-аллокация IP в org — пока НЕ снять: UI/бэкенд не даёт удалить ipSpace, пока есть дочерние инстансы (подтверждено 2026-09-22). Нужен чистый org или плановый teardown. Гипотеза payload — vIPConfigure=[] (unverified).
2. ✅ Имя ipSpace — выбор ИЗ СПИСКА (подтверждено UI). Свободного ввода нет → список динамический (текущие ipSpace org + no-needed). Следствие для провайдера: ip_space_name в SNAT-модификаторе должен браться из computed-вывода org-модификатора, а не быть свободной строкой.
3. 🟡 Полное удаление ipSpace и поведение при destroy Edge с включённым SNAT — на будущее (блокировано п.1).