chore: save current changes

2026-09-23 19:23:31 +03:00
parent d78573de45
commit a96e38fb1e
8 changed files with 994 additions and 0 deletions
@@ -0,0 +1,51 @@
+# Промпт для Opus: IaC-развёртывание Штурвала, проблема `modify` и скрытых зависимостей
+
+## Правила ответа (жёстко)
+
+1. НЕ лезь в файлы/репозиторий/сеть. Отвечай ТОЛЬКО по материалу ниже.
+2. Отвечай КРАТКО, тезисами, по номерам вопросов. Без простыней.
+3. Токены/секреты/креды НЕ нужны — если захочешь, не упоминай и не проси.
+4. Если для ответа не хватает данных — прямо пиши «неизвестно», не выдумывай.
+5. Не предлагай «ручной ЛК / скрипт / пресеты дефолтного окружения» как решение IaC — это уже отклонено (клиенту нужен полноценный IaC).
+
+## Контекст
+
+Terraform-провайдер для Nubes Cloud. Клиенту нужен IaC: один конфиг + `terraform apply` = вся инфраструктура. Цепочка Штурвала:
+
+```
+vcOrg    -> create
+vcVdc    -> create
+vcNsxt   -> create
+vcOrg    -> modify   (аллокация внешних IP)
+vcNsxt   -> modify   (включить SNAT, указать внешний IP из vcOrg)
+k8sShturval -> create
+```
+
+Операции строго последовательны.
+
+Факты (подтверждены):
+- Провайдер генерируется из YAML-спеков. Схема tf-ресурса строится ТОЛЬКО из операции `create`.
+- `vIPConfigure` (array-map-fixed, sub: name/count) есть только в `modify` vc_org (id 207); в `create` (136) его нет.
+- `ipSpaceName` (string) есть только в `modify` vc_nsxt (id 111); в `create` (10) его нет.
+- `vIPConfigure` — накопительный: повторный `modify` выделяет IP заново, а не задаёт состояние.
+- `ipSpaceName` выводится из цепочки `providerVdc -> providerGateway -> ipSpace`, которую пользователь не знает. Сейчас платформа «подкладывает» недостающие параметры при создании пустой орги.
+- Допущение платформы: в организации один T0/провайдер-шлюз. Рост числа T0 отложен.
+- Платформа в движении: форма ресурсов зависит от новых спеков (ждут, придут сначала в sandbox).
+
+Прецедент (VCD): та же цепочка делается отдельными ресурсами с `depends_on` — `vcd_nsxt_alb_settings` (count + is_active), `vcd_nsxt_alb_edgegateway_service_engine_group` (reserved_virtual_services), `vcd_network_routed_v2`, `vcd_ip_space_custom_quota` (на оргу). Включение/выключение = `count`, inverse = удаление ресурса.
+
+Разница с каноном: у нас нет отдельного API-объекта под модификацию — только операция `modify` над родителем (Read = чтение родителя, Delete = обратный modify, нужна идемпотентность).
+
+## Вопросы
+
+1. Как корректно выразить накопительный `vIPConfigure` идемпотентным tf-ресурсом (чтобы повторный apply не выделял IP заново)? Как устроить Read и Delete (inverse: обнулить count), если отдельного API-объекта нет?
+
+2. Как провайдер должен получать выводимое значение `ipSpaceName` (цепочка providerVdc → providerGateway → ipSpace): data-source, вычисляемое из state родителя, или иное? Где граница «данные vs логика», что хранить в реестре, что выводить из типа/state?
+
+3. Как спроектировать форму ресурсов, чтобы не завязываться на допущение «в организации один T0», и что сломается/что менять, если T0 станет больше одного?
+
+4. Стоит ли ждать новых спеков платформы перед проектированием ресурсов, или форму ресурсов можно зафиксировать уже сейчас так, чтобы она пережила изменение спеков? Что в спеках — блокер, что — нет?
+
+5. Минимально-инвазивный порядок внедрения: что должно прийти от платформы (spec/API) до того, как мы начинаем кодить, а что можем сделать на стороне провайдера уже сейчас?
+
+Отвечай по номерам, кратко.