tf_provider/prompt_for_opus_modifier_review_2.md

Ревью: модификаторы vc_nsxt / vc_org + досылка modify-params (Terraform Provider Nubes)

Ты — ревьюер. Ничего не правь. Прочитай и выдай:

1. подтверждение/опровержение каждого утверждения ниже;
2. список багов/рисков, которые я НЕ заметил;
3. список проблем, которые я заметил ошибочно (ложные тревоги);
4. чёткую рекомендацию по каждому корректному фиксу (минимальную, без scope creep).

Контекст системы

Go Terraform provider terraform-provider-nubes (plugin-framework), сервис Nubes Cloud. Генератор ресурсов: TOOLS/resource-generator (шаблон instance.go, modifier.go). Ядро: provider/internal/core/ (HTTP + операции), provider/internal/resources_core/ (обёртки).

Сервисы, о которых речь:

• vc_nsxt (serviceId 22). Операции: create (10), delete (25), modify (111, kind: modifier, modifier: network), reconcile. У resource НЕТ instance-modify.
• vc_org (serviceId 19). Модификатор ip_space (modify 207).

Модификатор = отдельный TF resource (nubes_vc_nsxt_network, nubes_vc_org_ip_space), который вызывает операцию modify с параметрами.

Цель (FullPipe) — что должно работать

1. Создать VDC (vc_vdc).
2. Создать Edge (vc_nsxt) с ALB (needEnableAVI=true, virtualServicesCount=3).
3. Выделить IP организации (vc_org → modifier ip_space, vIPConfigure).
4. Применить SNAT для Edge (vc_nsxt → modifier network, ipSpaceName + routedNetConfiguration).

Что УЖЕ сделано (факты, проверь корректность)

Факт 1. resource "nubes_vc_nsxt" Update — no-op

Шаблон instance.go генерирует hasServiceParamChanges := false, а цикл по .ModifyParams пуст (у vc_nsxt нет instance-modify). Поэтому Update всегда уходит в if !hasServiceParamChanges { ...; return } и НЕ вызывает modify (111). Изменение ALB/VS/qos через resource невозможно. Изменения Edge идут ТОЛЬКО через модификатор nubes_vc_nsxt_network.

Факт 2. Досылка незаданных modify-params (мой свежий фикс, коммиты a011358)

Раньше незаданные params операции modify досылались значением paramValue из GET /instanceOperations/{opUid}?fields=cfsParams. Это ОШИБОЧНО: paramValue — дефолт ФОРМЫ операции, а не состояние инстанса. Для needEnableAVI там "false", хотя live-значение инстанса true (подтверждается HAR/edge_.har и HAR/ipSpace0.har). Из-за этого каждый modify через модификатор сбрасывал ALB в false.

Фикс: в operation_cfs.go добавлены instanceLiveParams() (читает live из GET /instances/{uid} → state.params) и lookupLiveParam(live, cfsParam). В runInstanceOperationByCode и RunInstanceOperationUniversalWithDefaults приоритет теперь: live state.params → paramValue → defaultValue.

Факт 3. ShouldRemoveFromState (коммит 94c4c44)

Раньше вызывал валидирующий GetInstanceState, который на статусе deleted кидал instanceDeletedError — и Read модификатора падал с "экземпляр … удалён" вместо тихого удаления из state. Переписан на GetInstanceStateRaw + различение 404/deleted (remove=true) vs сеть/5xx/403 (нужно false, err).

ОШИБКА, которую наблюдаю СЕЙЧАС (главное)

terraform apply падает:

Error: Provider returned invalid result object after apply
After the apply operation, the provider still indicated an unknown value for
nubes_vc_nsxt.edge.qos_profile. All values must be known after apply...

qos_profile у resource nubes_vc_nsxt = Optional+Computed БЕЗ Default (ShouldBeOptionalComputed → true, потому что param qosProfile: not required, RefSvcId=0, Default=""). В конфиге не задаётся → в плане unknown. А Update (hasServiceParamChanges=false → ранний return) копирует только State*/Vault* outputs, но НЕ вызывает RefreshResourceState, поэтому qos_profile остаётся unknown.

МОИ ДИАГНОЗЫ (проверь каждый, а не только текущий)

Диагноз A (текущая ошибка)

Ранний return в Update (шаблон instance.go) не схлопывает unknown→null read-back-computed поля. Нужно в ветке !hasServiceParamChanges вызывать тот же RefreshResourceState, а не копировать State*/Vault* вручную.

Диагноз B (вылезет после A)

Тот же ранний return оставляет unknown для need_enable_avi и virtual_services_count, если их убрать из edge.tf (а их и должны убрать, раз ALB перенесён в модификатор). Один корень с A.

Диагноз C (дублирование конфига — НЕ починен)

edge.tf ДО СИХ ПОР задаёт need_enable_avi и virtual_services_count (create), а edge_network.tf — те же значения (modifier). Это двойное задание одного и того же → возможен дрейф. Нужно определить: где канонически задавать ALB?

Диагноз D (ловушка destroy/delete)

Модификатор имеет delete_strategy: inverse, override needEnableAVI="false". При terraform destroy ALB выключится. Повторный apply через resource "nubes_vc_nsxt" (no-op Update) НЕ включит обратно, а включит только модификатор второй apply-волной. Нужно проверить порядок зависимостей.

Диагноз E

FetchInstanceOutputs глотает любую API-ошибку (5xx/404) и возвращает пустые outputs без diagnostic → молчаливый дрейф. Нужен warning.

Конкретные вопросы

1. Подтверди/опровергни Диагноз A как корень текущей ошибки.
2. Есть ли проблема в моём фиксе досылки (Факт 2)? В частности:
   • верно ли, что state.params — единственный достоверный источник live?
   • не сломает ли lookupLiveParam (по Code/SvcOperationCfsParam/Name/Label) какие-то кейсы, где имя в state.params отличается регистром/форматом от этих ключей?
   • не создаёт ли instanceLiveParams лишний сетевой вызов на каждый modify (перф)?
3. Верна ли трактовка Факт 1 (resource Update — no-op)? Или правильнее ДОБАВИТЬ instance-modify в генератор?
4. Какое каноническое место для need_enable_avi/virtual_services_count/qos_profile: create (edge.tf) или modifier (edge_network.tf)? Что делать с текущим дублированием?
5. Что ещё я упустил в цепочке create→modify→read→destroy?