# Проверка модификатора 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.