tf_provider/docs/ORG_IP_MODIFIER_TEST_2026-09-22.md

Проверка модификатора vc_org ip_space (modify 207) — 2026-09-22

Организация: NarodOrg (9890a8a0-040b-4d56-8018-c31519c35a30), realm sandbox.nubes.ru. Стенд: DEV_STAND/FullPipe, провайдер nubes-dev 2.0.9.

Что делали

1. Переименовали org_ips.tf → terraform apply — ошибок нет (ресурс ушёл из state; Delete модификатора — no-op).
2. Вернули файл → apply — ошибок нет, число IP осталось 1 (повторный modify с тем же count=1 НЕ задвоил).
3. org_ip_count = 2 → apply — стало 2.
4. org_ip_count = 1 → apply — стало 1.
5. org_ip_count = 0 → apply — стало 0.

Подтверждено по API

GET /instances/9890a8a0-040b-4d56-8018-c31519c35a30:

• state.params.vIPConfigure = [{"name":"internet-ipv4-v1","count":0}]
• последняя операция modify — isSuccessful: true, isPending: false, isInProgress: false.

Выводы (обновляют прежние гипотезы)

1. modify работает в обе стороны (count вверх/вниз/до 0) на здоровой орге, даже при живых дочерних инстансах (VDC/Edge).
2. modify идемпотентен — повторный modify с тем же count не аккумулирует IP (1 → 1).
3. count=0 принимается, хотя в схеме операции 207 у count стоит minvalue: 1 / integer > 0 — валидация не отвергает 0. count=0 = ноль выделенных IP (элемент ipSpace остаётся в state).
4. Delete модификатора — no-op подтверждён (шаг 1), но это восполнимо: повторный apply с нужным count корректно восстанавливает состояние.

Опровергнуто

• Утверждение из docs/HAR_SNAT_MODIFY_FINDINGS.md «уменьшить/удалить ipSpace нельзя, пока существуют дочерние инстансы» — не подтвердилось на здоровой орге (в HAR был сломанный Edge; это и было помечено как неподтверждённое наблюдение).
• Опасение из Opus-ревью о «двойном выделении при replace/destroy→apply» — в части повторного modify с тем же count не воспроизвелось (идемпотентно).

Открытый вопрос

• Полное удаление ipSpace (пустой массив [] / отсутствие элемента) не тестировалось — count=0 оставляет элемент {"name":"internet-ipv4-v1","count":0} в state.