Files

T

Repinoid fbc20eea61 fix(generator): нормализация имён атрибутов (fail-safe для кодов с дефисами)

Инцидент: в 1_dummy (API dev) появились коды s3-inst / s3-ref-root. ToSnake не убирал
дефисы -> в схему уходило tfsdk:"s3-inst" -> Terraform отвергает такие имена и НЕ
загружает схему провайдера целиком (plan/apply падали).

- helpers.go: ToSnake завершается sanitizeAttrName ([a-z0-9_] допустимы, остальное -> _).
  Код для API не меняется: json:"s3-inst" в генерате сохранён.
- Проверено: в generated/dev/go нет tfsdk-имён с недопустимыми символами;
  go build OK; go test ./internal/... -short PASS.
- DEV_STAND/FPipeGmail: провайдер 2.0.23 -> 2.0.1; после сброса lock/кэша
  terraform validate -> Success.
- HISTORY: описан инцидент, причина (данные API изменились после утра), фикс и
  особенность: перезапись артефакта под тем же номером требует сброса lock
  (init -upgrade хеш не пересчитывает).

dev 2.0.1 перезалит (sha256 linux d25a71a31dbc9ab16e494b3d1f68b38b2214bd530045c5a3003f515bc725e407).

2026-09-30 21:42:37 +03:00

5.8 KiB

Raw Blame History

Релиз dev-провайдера 2.0.1 (2026-09-30)

Стенд: dev. Namespace: nubes-dev/nubes. Версия: 2.0.1. Команда: ./TOOLS/scripts/03_build_and_upload_provider.sh --profile TOOLS/config/dev (цикл: 01 YAML из API → 02 Go-ресурсы + доки → сборка 3 платформ → SHA256SUMS → GPG → заливка 5 объектов в S3).

Что вошло (правки сессии по итогам анализа и ревью)

Правка	Файл
Транзиентный 401 ретраится для GET	`core/http.go`
Partial state при ошибке после создания инстанса (Q5)	`core/instance_create.go`, `templates/instance.go`
Idempotency pre-check по live без схемы операции	`core/modifier_compare.go`, `core/operation_run_bycode.go`
ImportState модификаторов заполняет Required	`resources_core/{nsxt_snat,org_ip_allocation}_resource.go`
Страж хардкодов покрыл `provider/`	`TOOLS/scripts/check_hardcoded_service_ids.sh`

Документация: TOOLS/ARCHITECTURE.md (разделы «API Resilience», «Modifier Idempotency», «Lifecycle Vocabulary»), HISTORY/2026-09-30_core_and_modifiers_remediation.md.

Проверки после заливки

Проверка	Результат
sha256 локальной сборки vs `SHA256SUMS` (linux/amd64)	✅ совпадает (`868518880edafccdf723806e6a136d083ee433a1d1d0ffb06737995810a68e8d`)
Локальный размер linux-архива	13 172 824 B
`GET /v1/providers/nubes-dev/nubes/versions`	✅ содержит `2.0.1` (+ `2.0.0`, `2.0.21`–`2.0.24`)
`GET /v1/providers/nubes-dev/nubes/2.0.1/download/linux/amd64`	✅ HTTP 200 (302 на presigned S3)
Объекты в S3	5 шт. (3 zip + `SHA256SUMS` + `SHA256SUMS.sig`), загрузка 37.92 MiB

⚠️ Примечания

Версия 2.0.1 создана заново — ранее она входила в диапазон 2.0.0–2.0.20, физически удалённый из dev-реестра (см. HISTORY/2026-09-30_dev_registry_prune_versions.md).
VERSION в TOOLS/config/dev/profile.env: 2.0.0 → 2.0.1.
test и prod не перезаливались — правки ядра в них не включены (по указанию владельца).
Версия 2.0.0 в реестре осталась от предыдущей заливки (там правок нет).

Инцидент при первой заливке: невалидные имена атрибутов (`s3-inst`, `s3-ref-root`)

Симптом. После первой заливки 2.0.1 провайдер не мог отдать схему: Invalid Attribute/Block Name: "s3-inst" at schema path "map_fixed.s3-inst", "s3-ref-root" at schema path "s3-ref-root" → падали terraform plan/apply/validate.

Причина. В API dev-стенда в тестовом сервисе 1_dummy появились параметры с кодами с дефисами (s3-inst, s3-ref-root). Проверено по бэкапам YAML: в наборах от 09:50, 10:15 и 11:05 (из последнего собрана рабочая 2.0.0) их нет, в наборе от 21:35 — 2 вхождения. То есть данные изменились на стороне платформы уже после утренней заливки. ToSnake не удалял дефисы → в схему уходило tfsdk:"s3-inst", Terraform отвергает такие имена (допустимы только [a-z0-9_]) и целиком не загружает схему провайдера.

Фикс. TOOLS/resource-generator/internal/helpers/helpers.go: ToSnake завершается sanitizeAttrName — всё вне [a-z0-9_] заменяется на _ (s3-inst → s3_inst). Код для API не меняется: json:"s3-inst" в генерате сохранён (это значение поля, а не имя атрибута). Проверено: в сгенерированном коде не осталось ни одного tfsdk:"…" с недопустимыми символами; сборка и go test ./internal/... -short — зелёные.

Повторная заливка. 03 прогнан заново (та же версия 2.0.1), sha256 нового linux-артефакта: d25a71a31dbc9ab16e494b3d1f68b38b2214bd530045c5a3003f515bc725e407.

Важно про локальный кэш. После перезаписи артефакта под тем же номером Terraform продолжает использовать старый файл: init -upgrade хеш не пересчитывает (версия и constraint не изменились). Лечится удалением .terraform.lock.hcl + .terraform и повторным init. Для внешних потребителей, которые ставят 2.0.1 впервые, проблемы нет — lock получит новый хеш.

Верификация. DEV_STAND/FPipeGmail: провайдер 2.0.1 (после сброса lock) → terraform validate — Success.

Не закрыто (предложение). В пайплайне нет проверки схемы: 02/сборка/заливка проходят при невалидных именах атрибутов, дефект обнаруживается только при обращении Terraform к провайдеру. Стоит добавить шаг валидации схемы в 03 (или fail-fast в генераторе по [a-z0-9_]).

5.8 KiB Raw Blame History Unescape Escape