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 (reverse) в HAR НЕ записана — есть только добавление. Payload удаления/уменьшения не подтверждён. 🔴 Ограничение (подтверждено): уменьшить/удалить 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 фигурирует и в стейте.

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

1. 🔴 Де-аллокация IP в org: записать HAR при удалении ipSpace / уменьшении count → какой payload (count=0? опустить элемент? отдельная операция?).
2. � valueList у ipSpaceName: динамический (текущие ipSpace org) или фиксированный? Проверить до/после добавления ipSpace.
3. 🟡 Имя ipSpace: свободный ввод или выбор из списка? Есть ли ограничения/уникальность?
4. 🟡 Полное удаление ipSpace (не уменьшение count) и что UI делает при destroy Edge с включённым SNAT.