docs(notes): Q&A с Opus по дизайну ресурсов-модификаторов + замечания к ответам
This commit is contained in:
Repinoid
@@ -0,0 +1,75 @@
|
||||
# Q&A с Opus: дизайн ресурсов-модификаторов (2026-09-24)
|
||||
|
||||
> Кто: вопросы составлены нами (Copilot), ответы — Opus (внешний агент, по разрешению пользователя).
|
||||
> Контекст: решено делать два ресурса-модификатора (`nubes_vc_org_ip_allocation`, `nubes_vc_nsxt_snat`).
|
||||
> Статус: ответы приняты к сведению, **код не писался**, часть утверждений Opus мною не проверена (пометки ниже).
|
||||
|
||||
## Вопросы и ответы
|
||||
|
||||
### 1. Инварианты Read/Delete ресурса-модификатора
|
||||
**Ответ Opus:**
|
||||
- Read: `RemoveResource` только если родитель исчез (404/deleted) — у нас есть `ShouldRemoveFromState`
|
||||
(Opus ссылается на `modifier.go`). Расхождение значения параметра ≠ повод удалять ресурс: это дрейф,
|
||||
обновить поле в state.
|
||||
- Delete = inverse modify (`count=0` / `needEnableAVI=false` / `ipSpaceName="no-needed"`) — «шаблон
|
||||
`DeleteStrategy=inverse` + `override` уже реализован».
|
||||
- Если родитель уже удалён: inverse пропустить, ресурс убрать из state (no-op + Warning), не падать на ошибке API.
|
||||
|
||||
### 2. Reset-to-default в `*WithDefaults`
|
||||
**Ответ Opus:** защита «уже встроена»: и `RunInstanceOperationUniversalWithDefaults` (`operation_run.go:138`),
|
||||
и by-code путь (`operation_run_bycode.go:108`) досылают незаданные параметры с приоритетом
|
||||
**live `state.params` → `paramValue` формы → `defaultValue`**. Достаточно шлать только `ipSpaceName`.
|
||||
Отдельный pre-read live + merge делать не нужно; `ByCode`/`ByIdempotent` — не нужны.
|
||||
Дополнительно `RunOperationByCodeIdempotent` (`check_before_run`) сверяет desired == current и пропускает лишний run.
|
||||
|
||||
### 3. Генератор: modify-only параметр с `required: true`
|
||||
**Ответ Opus (минимальный набор):**
|
||||
- **(а)** modify-only → всегда Optional (снять Required в схеме). Обязательно.
|
||||
- **(б)** исключить modify-only из create-read-back (не добавлять его `InputField` в Create/Read). Обязательно.
|
||||
- **(в)** «после create догонять modify» — **не нужно**: это ответственность отдельного modifier-ресурса.
|
||||
- Breaking: снятие Required — не breaking (Optional шире). Breaking — если **удалить** атрибут из схемы
|
||||
instance у тех, кто его уже прописал в `.tf`. Формулировка Opus: «modify-only параметров в схеме instance
|
||||
быть не должно вовсе — их место в modifier-ресурсе».
|
||||
|
||||
### 4. Диагноз «inconsistent result after apply» на создании орги
|
||||
**Ответ Opus: подтверждает.** `state_refresh.go`, цикл `inputs`: берёт `paramsMap["vIPConfigure"]` из
|
||||
`state.params` (платформа отдаёт `[{}]`), через `setFieldValue`/`ParseString` перекрывает план; для
|
||||
Required-атрибута TF требует final == config → ошибка. Корректно: не читать modify-only обратно в Create
|
||||
(п.3б) и вернуть запланированное значение, либо Optional+Computed со схлопыванием `[{}]`→null.
|
||||
|
||||
### 5. Порядок destroy
|
||||
**Ответ Opus:** явный `depends_on` нужен — связь между org-IP и SNAT идёт по **имени** ipSpace, ребра графа
|
||||
TF не видит. Цепочка: `vdc → org → org-IP → edge → SNAT → кластер`; при корректных `depends_on` destroy
|
||||
пойдёт в обратном порядке. Обязательные рёбра: SNAT → org-IP, modifier → родитель. Достаточно при условии,
|
||||
что inverse-Delete терпит уже удалённого родителя (п.1).
|
||||
|
||||
### 6. Трактовка `[{}]` в Read
|
||||
**Ответ Opus:** `[{}]` = «не выделено», нормализовать в null/пусто. `count=0` и `[{}]` — одно состояние
|
||||
«пусто», иначе ложный дрейф на каждом plan.
|
||||
|
||||
## Мои замечания к ответам (не проверено кодом, требует внимания)
|
||||
|
||||
1. **Opus опирается на machinery отменённого захода.** Он говорит про `modifier.go`, `DeleteStrategy=inverse`,
|
||||
`override`, «уже реализовано». Это шаблон генератора из эпохи `kind: modifier`, которую мы **сознательно
|
||||
отменили** (см. баннер LEGACY в `NOTES/20_prompts/**`, `docs/60_strategy/modifier_resources_ideology_and_specification.md`).
|
||||
Ответы про «уже встроено» нельзя принимать как готовое решение — это код отменённой ветки.
|
||||
2. **Противоречие внутри п.3:** сначала «modify-only → всегда Optional (оставить в схеме instance)»,
|
||||
потом «modify-only в схеме instance быть не должно вовсе». Это разные изменения: Optional+Computed vs удаление.
|
||||
Нужно выбрать одно, иначе получим двух владельцев одного параметра (instance-ресурс и модификатор).
|
||||
3. **Два владельца параметра.** Если `ip_space_name` остаётся в `nubes_vc_nsxt` **и** появляется
|
||||
`nubes_vc_nsxt_snat`, Terraform не увидит конфликт: оба будут шлать 372. Значит, из `Update`
|
||||
сгенерированного `nubes_vc_nsxt` параметр надо убирать — иначе fight/drift. В ответах Opus этого нет.
|
||||
4. **П.2 не проверял сам.** Утверждение «приоритет live → paramValue → defaultValue уже встроен» противоречит
|
||||
комментарию в `19_vc_org_resource.go` про reset-баг (`state_params["needEnableAVI"]="false"`, когда на
|
||||
платформе `true`). Нужна проверка `operation_run.go:138` и `operation_run_bycode.go:108` по коду.
|
||||
5. **Политика destroy для не-нашей орги.** Орга не в state (адресация по uid). При `destroy` конфигурации
|
||||
родитель не удаляется — но org-IP-модификатор по §1 выполнит inverse (`count=0`). Нужно решение:
|
||||
снимать квоту или оставлять (`keep_on_destroy`)— у Opus этого нет.
|
||||
6. **Один элемент vs весь массив.** `vIPConfigure` — массив. Если ресурс управляет одним элементом
|
||||
(по `ip_space_name`), то два ресурса на разные ipSpace возможны; если всем массивом — нет. `count=0`
|
||||
как inverse предполагает поэлементную модель, но в ответах это не зафиксировано.
|
||||
|
||||
## Что дальше (после решения пользователя)
|
||||
|
||||
- Проверить по коду п.2 и п.4 замечаний (чтение, без правок).
|
||||
- Дописать план реализации 2 ресурсов с учётом п.3 и п.5.
|
||||
Reference in New Issue
Block a user