docs(modifier): анализ inverse-архитектуры + промпты Опусу (глобальная архитектура оверлея)

2026-09-23 08:43:56 +03:00
parent d5dc1212ba
commit 20ea79a489
3 changed files with 145 additions and 0 deletions
@@ -0,0 +1,47 @@
+# Вопрос: архитектура inverse-отката модификаторов (без чтения файлов)
+
+ЗАПРЕЩЕНО лезть в файлы репозитория. Отвечай только по тексту ниже. Ответ — максимально краткий (тезисы), но исчерпывающий.
+
+## Контекст
+
+Terraform provider для Nubes Cloud. Есть «модификаторы» — отдельные TF-ресурсы, вызывающие операцию `modify` над инстансом по кодам параметров, а не по числовым id. Примеры:
+- `vc_org` → модификатор `ip_space`, параметр `vIPConfigure` (array-map-fixed) = `[{"name":"internet-ipv4-v1","count":3}]` — выделение внешних IP.
+- `vc_nsxt` → модификатор `network`, параметры `needEnableAVI` (boolean), `ipSpaceName` (string, valueList содержит sentinel `"no-needed"`), `routedNetConfiguration`.
+
+У модификатора есть `delete_strategy`, определяющий что делать при `terraform destroy`:
+- `noop_warn` — снять из state, эффект остаётся (предупреждение).
+- `error` — запрет удаления (сейчас так на vc_org, из-за чего destroy встаёт).
+- `inverse` — при Delete выполнить обратную операцию `modify` с `delete_params` (список `{Code, Value}`).
+
+## Проблема
+
+Хочу, чтобы `destroy` и `apply` были полными и симметричными. При удалении модификатора нужно «откатить» эффект:
+1. `needEnableAVI` → `false`.
+2. `ipSpaceName` → `"no-needed"`.
+3. `vIPConfigure` → `count=0`, имя сохранить (`[{"name":"internet-ipv4-v1","count":0}]`).
+
+Пункты 1-2 — статические константы, текущий механизм `delete_params {Code,Value}` покрывает.
+Пункт 3 — динамический: имя берётся из текущего state инстанса, обнуляется только `count`.
+
+Требование: решение должно быть архитектурно чистым и универсальным (привязанным к типам данных из API, `dataType`/`valueList`/`sub_params`), а не хардкодом имён сервисов — чтобы при неглобальных изменениях API перегенерация подхватывала.
+
+## Ключевые факты (уже проверены)
+
+- `count=0` принимается API, несмотря на `minvalue:1`/`integer > 0` в схеме. Идемпотентно.
+- `ipSpaceName` sentinel «выключен» = `"no-needed"` (есть в `valueList`).
+- `needEnableAVI` — boolean: обратное = `"false"`.
+- Типы из API: `needEnableAVI`=`boolean`; `ipSpaceName`=`string`(+`valueList`); `vIPConfigure`=`array-map-fixed` (sub_params: `name`=string, `count`=integer).
+
+## Вопросы (нужны краткие ответы)
+
+1. Как правильно расширить модель delete_params, чтобы поддержать и статичные обратные значения (`false`, `no-needed`), и динамические преобразования (`count→0`)? Оцени вариант «типизированные правила`: `Mode` ∈ {static, zero_count, …}, где static=текущий Value, zero_count=обнулить integer-поле `count` в каждом элементе array-map-fixed, взятом из live state.
+
+2. Универсальнее ли выводить обратные значения ИЗ ТИПА ПАРАМЕТРА (boolean→"false", string+valueList→первый/помеченный sentinel, array-map-fixed→нулевой count в integer-полях), чем задавать их в реестре исключений? Где баланс: что держать в реестре (данные), что выводить из типа (логика)?
+
+3. Нужен ли отдельный маркер «какое поле array-map-fixed обнулять» (сейчас это `count`), или достаточно общего правила «обнулить все integer-поля sub_params»? Риски обоих.
+
+4. Правильный порядок destroy при зависимостях: `edge_net` (SNAT off + ALB off) → `org_ips` (count=0) → `nsxt` → `vdc`. Как Terraform сам выведет порядок из `depends_on`, и где инверсия/откат может конфликтовать с порядком удаления дочерних инстансов?
+
+5. Есть ли подводные камни в самом `inverse`-delete (если дети ещё живы, откат `count=0` на орге может не пройти)? Нужен ли двухфазный подход или достаточно полагаться на порядок?
+
+Формат ответа: пункты пронумерованы под мои вопросы, 1-3 предложения на пункт. Без лишнего.