docs(plans): §12 — орга делается руками в ЛК, в tf только uid; правка генератора не блокер, нужны только 2 ресурса

2026-09-24 10:10:55 +03:00
parent cb8389c17f
commit 574e300476
1 changed files with 20 additions and 0 deletions
@@ -182,3 +182,23 @@ nubes_vc_nsxt  →  nubes_vc_org_ip_allocation  →  nubes_vc_nsxt_snat  →  k8

 **Следствие для наших решений:** критерий «кто делегируется» задаётся явным списком в конфиге генератора;
 работа разбивается на релиз A (маленький, безопасный) и релиз B (ресурсы + отцепка).
+
+---
+
+## 12. ⚠️ Уточнение пользователя (2026-09-24): оргу делаем РУКАМИ в ЛК
+
+**Факт:** орга создаётся вручную в ЛК и **в Terraform не заводится** — она одна на всё.
+В tf она используется только как uid для модификаций.
+
+**Что это меняет:**
+
+1. `nubes_vc_org` в конфигурации **не используется** → дефект «`inconsistent result after apply` при create орги»
+   для этой задачи **не блокер** (остаётся латентным дефектом ресурса).
+2. **Релиз A (правка create-read-back) становится необязательным** для цепочки Штурвала.
+3. `nubes_vc_nsxt`: править генератор **тоже не нужно** — достаточно **не задавать** `ip_space_name` в `.tf`.
+   Атрибут Optional+Computed: SNAT выставит модификатор, read-back подхватит значение в state, дрейфа не будет.
+4. Итог: для задачи нужны **только два новых ресурса** (`nubes_vc_org_ip_allocation`, `nubes_vc_nsxt_snat`),
+   оба адресуются по uid родителя. Правки генератора (§7, релизы A/B) — **отдельная тема**, не вход в эту работу.
+
+**Открытый вопрос:** эдж (`nubes_vc_nsxt`) создаётся Terraform или тоже руками? На состав работ не влияет
+(в обоих случаях нужны те же два ресурса), влияет только на пример конфигурации.