docs: убрать устаревшее «канонизация в plan-modifier» (совет Opus был неверен); план живого прогона FullPipe

2026-09-24 14:04:08 +03:00
parent 807dfde287
commit e25ef02a1a
3 changed files with 99 additions and 11 deletions
@@ -0,0 +1,78 @@
+# ПЛАН: живой прогон цепочки на DEV_STAND/FullPipe (2026-09-24)
+
+> Стенд: dev, орга **`organ`** (`57eeacd1-dc7f-4a52-b903-7e5f7d3c1164`, realm `sandbox.nubes.ru`, тип `saas`,
+> CD-имя `WZ01325-saas`). Провайдер `2.0.19` (`terraform init -upgrade` уже сделан, `validate` — Success).
+> **`apply`/`destroy` запускает только пользователь.**
+
+## 0. Что уже готово
+
+- Ресурсы `nubes_vc_org_ip_allocation` (modify `vIPConfigure`) и `nubes_vc_nsxt_snat` (modify `ipSpaceName`) —
+  в провайдере, собраны в `2.0.19`, залиты в `nubes-dev`, есть unit-тесты канонизации.
+- Конфиг стенда: `DEV_STAND/FullPipe/` — `vdc.tf`, `edge.tf`, `modifiers.tf` (аллокация после эджа, затем SNAT),
+  `organization = "organ"` + `org_uid`.
+- Орга создана вручную (в tf её нет) — по решению пользователя.
+
+## 1. Цель прогона
+
+Проверить **одним `apply`**: `vdc → edge → IP на орге → SNAT`, затем чистый повторный `plan` и корректный
+`destroy`. Это первый живой прогон обоих новых ресурсов: CRUD до сих пор не проверялся.
+
+## 2. Перед прогоном (проверить значения)
+
+1. `vdc_network_provider` (`snb1`), `vdc_provider_vdc` (`Intel Broadwell 2.4`), `vdc_storage_config` (`SATA`) —
+   убедиться в ЛК, что доступны для орги `organ` (значения брались из ЛК для прежней орги).
+2. `ip_space_name` — сначала может быть недоступен: **список ipSpace в ЛК падает** (`Can't cast Complex Object
+   Type Struct to String`), пока нет vDC/эджа. Брать имя из прежних HAR: `internet-ipv4-v1`.
+3. `ip_count` — `"3"` (строка).
+
+## 3. Шаги прогона (пользователь)
+
+| # | Команда | Ожидаемый результат |
+|---|---|---|
+| 1 | `terraform plan` | создание: `nubes_vc_vdc.vdc` → `nubes_vc_nsxt.edge` → `nubes_vc_org_ip_allocation.org_ip` → `nubes_vc_nsxt_snat.snat`; порядка не меньше |
+| 2 | `terraform apply` | всё создаётся за один проход |
+| 3 | `terraform plan` (повторно) | **пустой** — главный тест канонизации (иначе вечный diff) |
+| 4 | проверить API (см. §4) | `vIPConfigure` и `ipSpaceName` в live-состоянии |
+| 5 | изменить `ip_count` 3 → 2, `plan`+`apply` | меняется только аллокация, state сходится |
+| 6 | `terraform destroy` | порядок `snat (no-needed)` → `org_ip (count=0)` → `edge` → `vdc`; орги не касается |
+
+## 4. Что проверять и чем
+
+```bash
+TOK=$(tr -d '\n' < secrets/narodDEV.token)   # токен орги organ
+# состояние орги
+curl -s -H "Authorization: Bearer $TOK" 'https://lk-api-gateway-dev.ngcloud.ru/api/v1/svc/instances/<org_uid>'
+# состояние эджа
+curl -s -H "Authorization: Bearer $TOK" 'https://lk-api-gateway-dev.ngcloud.ru/api/v1/svc/instances/<nsxt_uid>'
+```
+
+**Гипотезы, которые прогон подтверждает/опровергает:**
+
+1. **Имена live-ключей**: `state.params.vIPConfigure` (орга) и `state.params.ipSpaceName` (эдж) — взяты из HAR,
+   кодом не проверены. Если Read вернёт не то → увидим дрейф/пустое значение.
+2. **Частичный payload не затирает остальное**: SNAT-модификация шлёт только `372`; `needEnableAVI`
+   и `virtualServicesCount` должны остаться прежними (`true` / `1`), т.к. досылаются из live
+   (`core/operation_run_bycode.go`). Проверить в состоянии эджа до/после.
+3. **Один `apply`** проходит целиком без второго прогона (ради этого и делались ресурсы).
+4. **Нет вечного diff** после apply (канонизация `vip_configure`).
+5. **`Required` + пустое live** не даёт ошибок (лечение из ревью).
+
+## 5. Точки отказа и что делать
+
+| Симптом | Вероятная причина | Действие |
+|---|---|---|
+| аллокация падает `Can't cast ... Struct to String` | платформа ещё не видит `job.vcd.networkProvider`/`providerGateway` (эдж/VDC не в состоянии) | проверить порядок и фактическое состояние эджа; при необходимости — пауза/повторный `apply` |
+| `Provider produced inconsistent result after apply` на `vdc`/`edge` | read-back перекрыл план (известный класс дефектов) | записать в NOTES, разбирать отдельно (это уже не про наши ресурсы) |
+| повторный `plan` не пустой | порядок ключей/формат не сошлись | сверить, что вернул live, с `formatVipConfigure` |
+| SNAT не включился | `372` не доехал / неверное имя ipSpace | проверить `state.params.ipSpaceName` эджа и лог операции |
+| `destroy` падает | обратный modify на живой/мёртвый родитель | смотреть тексты диагностик ресурсов (мы развели: ошибка API ≠ «родителя нет») |
+
+## 6. После прогона
+
+1. Отчёт в `NOTES/30_analysis/` — что прошло, что упало, с HAR/логами.
+2. Обновить память репозитория (подтверждённые факты вместо гипотез).
+3. Если найдутся баги — отдельные коммиты + при необходимости новый релиз провайдера.
+4. Публикация документации (`04_build_and_publish_docs.sh`) — отдельной командой.
+
+**Не входит в этот прогон:** кластер Штурвал (`nubes_k8s_shturval_cluster`) — отдельным шагом, после того как
+SNAT подтверждён.