Files

T

Repinoid 9aed2dcdd9 fix(provider): нормализация регистра UUID при отправке map-fixed JSON в API

- resources_core.BuildJSON оборачивает результат в jsonutil.LowercaseUUIDsInText:
  платформа сравнивает регистр UUID при create, а ресурсы отдают id в UPPERCASE
  (nsxtUid/vdcUid) -> без нормализации create Штурвала падал 'Edge не развёрнут
  в указанном vDC' (обнаружено на провайдере 2.0.23 из-под Windows).
- Одна точка покрывает все map-fixed-параметры (create/modify/redeploy),
  регенерация не требуется.
- Документация: HISTORY/2026-09-30, docs/60_strategy/terraform_case_sensitivity_fix.md §11,
  NOTES/30_analysis/ARCHITECTURE_NEW.md §6.5, docs/help/architecture-and-methods.md §7.

Не выпущено: версия не поднималась, релиз/регенерация не выполнялись.

2026-09-30 08:34:04 +03:00

4.4 KiB

Raw Blame History

Архитектура и методы (CRUD)

1. Актуальная архитектура (универсальный rebuild)

Ядро: universal_rebuild/internal/core (универсальный клиент API, общий flow операций).
Провайдер: universal_rebuild/internal/provider (schema, конфигурация, подключение ресурсов).
YAML-спеки сервисов: universal_rebuild/resources_yaml (источник истины).
Генератор Go-ресурсов: universal_rebuild/tools/gen (читает YAML, генерирует ресурсы и реестр).

Ключевое правило: новая логика — только новые функции/файлы. Существующий Go-код не менять без согласования.

2. Источник параметров (discovery)

Параметры сервиса извлекаются через proxy endpoint API:

/index.cfm?endpoint=/services/{svcId}
/index.cfm?endpoint=/serviceOperation/{svcOperationId}
(опц.) /index.cfm?endpoint=/param-value-list/{svcOperationCfsParamId}

Схема: сервис → операции → CFS параметры → YAML → генерация Go.

3. Универсальный Create (7 шагов)

POST /instances → instanceUid
POST /instanceOperations (create) → instanceOperationUid
GET /instanceOperations/{uid}?fields=cfsParams
POST /instanceOperationCfsParams для каждого параметра
GET /instanceOperations/{uid}/validate-cfs
POST /instanceOperations/{uid}/run с payload {}
Polling до завершения операции

Критично: параметры отправляются все, включая дефолты, иначе бэкенд может упасть на валидации.

4. Read/Adopt

При isDeleted или explainedStatus=deleted — state очищается.
При статусе running adopt допускается только при adopt_existing_on_create=true.
При статусе suspend допускается resume только при совпадении основных параметров.
Предупреждения показываются только на create и не мешают managed ресурсам.

5. Update/Modify

IDs параметров на modify отличаются от create.
Нельзя хардкодить ID, нужно получать manifest операции и строить маппинг.
Если modify отсутствует в availableOperations — выдавать ясную ошибку.

6. Polling (железные правила)

Завершение операции определяется только по dtFinish.
После dtFinish результат определяется isSuccessful.
Для VM применяется двойной контроль: статус операции + статус инстанса (ERROR/STOPPED).

7. Нормализация типов

map/json → "{}"
list/array → "[]"
Пустые строки в JSON-параметрах запрещены (валидаторы на plan).
UUID-подстроки в JSON (map-fixed) приводятся к lowercase и при сравнении, и при отправке в API (resources_core.BuildJSON → jsonutil.LowercaseUUIDsInText). Платформа сравнивает регистр UUID при create, а ресурсы могут отдавать id в UPPERCASE (например nsxtUid). Поэтому lower(...) в конфигах стендов не нужен — см. docs/60_strategy/terraform_case_sensitivity_fix.md §10–§11.

8. Soft Delete и карантин

Для тяжёлых ресурсов delete часто заменён на suspend с периодом удержания.
Для сервисов с suspend/resume действует флаг suspend_on_destroy:
- true (default) -> выполнять suspend;
- false -> удалять только из Terraform state (без API-вызова).
Повторный apply при suspend может выполнять resume только при совпадении ключевых параметров.

4.4 KiB Raw Blame History Unescape Escape