Новый файл HISTORY/2026-10-02_s3_static_website_docs_hosting.md:
- итог живой проверки: у Nubes включён static website на Ceph RGW (Squid),
сайт целиком работает из S3 без ВМ; незакрыт только домен/TLS (принадлежит Nubes);
- единственное изменение состояния: PUT Bucket website (IndexDocument=index.html)
на бакете terraform-registry + команда отката; статус — оставлено, решения владельца нет;
- найдено уже настроенным у Nubes: NoSuchWebsiteConfiguration до PUT (значит API есть),
wildcard DNS *.s3-website.msk-1.ngcloud.ru -> 89.169.61.167, валидный TLS,
порт 80 закрыт, bucket policy PublicReadGetObject (Principal *);
- проверки: анонимные 200 с размерами, совпадающими с index.html (148758/139835/150021),
фактическая раскладка ключей docs/{nubes,nubes-dev,nubes-test}/nubes/…,
объектный эндпоинт каталоги не умеет (403) — резолвинг только на website-эндпоинте;
- зафиксирована моя ошибка: 403 приходили на НЕСУЩЕСТВУЮЩИЙ ключ docs/nubes/index.html;
уроки — сначала list-objects-v2, потом URL; сверять размеры и проверять анонимно+подписанно;
- побочные находки: list-buckets видит бакеты других тенантов; в secrets/.s3cfg_registry
лежат чужие ключи (tazet@narod.ru, ntazetdinov@nubes.ru);
- версии развития V0 (213+nginx) -> V1 (website-эндпоинт, проверена) -> V2 (origin их фронта),
отклонённые V3a/V3b/V3c и чек-лист дальнейших изменений.
- VERSIONS.md: новые sha256 всех трёх сборок;
- HISTORY: разбор бага (Computed-атрибут оставался unknown в ветках усыновления),
что правилось в 64328ab и 93784e4, проверки до заливки, а также зафиксированы
ошибки исполнителя (правки без разрешения, лишняя перегенерация, неверная
оценка в первом ревью).
По итогам код-ревью (коммит 64328ab):
- ResolveUserPasswordFromVault теперь возвращает и текст предупреждения: если пароль
прочитать не удалось (недоступен API/Vault, пустое имя, нет записи), в выводе apply
появляется Warning. Раньше поле молча становилось null и причина была невидима.
Отсутствие секретов у родителя ошибкой не считается (для части сервисов это норма).
- В шаблоне подресурса заполнение вынесено в одно замыкание applyPassword(),
вызываемое перед каждым resp.State.Set в Create (4 сохранения — 4 вызова).
Убирает четыре одинаковые строки и снижает риск забыть новую ветку выхода.
- Тест проверяет: замыкание есть, предупреждение есть, и вызовов applyPassword()
не меньше, чем сохранений состояния в Create.
Проверено: generated/test/go/90_postgres_user_resource.go — 4 State.Set, 4 вызова
(плюс одно упоминание в комментарии); go test ./... ok; go build ./internal/... и
полная сборка провайдера во временной копии с новым generated — чисто.
Баг (воспроизведён на TEST 2026-10-01): при усыновлении уже существующего
пользователя БД Create выходит по раннему return (ветка 'Подресурс уже существует'
-> State.Set -> return), оставляя Computed-атрибут password в состоянии unknown.
Terraform отказывался: 'Provider returned invalid result object after apply: the
provider still indicated an unknown value for nubes_postgres_user.crud_user_0.password'.
Исправление:
- новая функция resources_core.ResolveUserPasswordFromVault(ctx, client, instanceUID,
username, current): читает пароль из Vault родителя, иначе возвращает current,
иначе типизированный null (null для Terraform — конкретное, known значение);
- в шаблоне подресурса password инициализируется null сразу после получения
instanceUID, а перед КАЖДЫМ resp.State.Set в Create проставляется конкретным
значением — включая все ветки усыновления;
- регрессионный тест усилен: считает сохранения состояния и вызовы заполнения в
Create и падает, если хоть в одной ветке password останется unknown.
Проверено: generated/test/go/90_postgres_user_resource.go — 4 State.Set и 4
вызова заполнения; go test ./... ok; go build — чисто.
Каталог tfluceecrud был закоммичен как submodule-указатель (mode 160000) без
.gitmodules — из-за этого git считал его 'изменённым' после каждого коммита в
самом репозитории приложения и правило .gitignore:16 на него не действовало.
Теперь структура однородна: tfluceecrud, tfflaskcrud, tfnodejscrud — отдельные
репозитории, лежащие локальными клонами рядом с основным репо и не входящие в
него (все три перечислены в .gitignore, строки 16-18). Файлы на диске не тронуты.
Ветка gitlink'ов apps/iot-* не затронута — они к этой задаче не относятся.
Прежние домены (tfflask / tflucee / tfnodejs) заняты старыми инстансами:
crud-flask suspended (с зависшей операцией), crud-lucee suspended, crud-nodejs running.
Создание новых сервисов с теми же доменами платформа отвергла бы как
'domain уже используется другим инстансом'.
Домен указан без точек, поэтому A-запись создаётся автоматически в служебной
DNS-зоне ресурсной платформы.
terraform validate — Success.
- старые x.0.0 удалены физически из реестра по команде владельца, затем залиты заново
теми же номерами; sha256 всех трёх сверен с локальными сборками;
- VERSIONS.md: новые sha256 + пометка об удалении версий;
- HISTORY: зачем, что удалено, схема залитой сборки (password — новый выход у
postgres_user/kafka_user/clickhouse_user/mongodb_user; у mariadb_user и pgadmin
это прежние входные параметры), проверка стенда, состояние state.
output pg_password = nubes_postgres_user.crud_user_0.password — значение известно в том
же apply, где создан пользователь, поэтому ни try(), ни двух apply в pg/ больше не
требуется. Обновлён комментарий про порядок вычисления.
Проблема: у части сервисов пароль пользователя генерирует платформа и кладёт его в
секрет Vault РОДИТЕЛЬСКОГО инстанса. vault_secrets родителя — Computed и обновляется
только при его Read, поэтому внутри одного apply после create_user пароль недоступен
(Invalid index). Из-за этого в pg/outputs.tf приходилось читать vault_secrets кластера,
а стенду требовались два apply.
Решение: подресурс-пользователь отдаёт пароль СВОИМ выходом сразу после create_user.
- types.go: GenSubresource.VaultUserPassword (признак из данных спека);
- loader.go: признак = подресурс user + у сервиса есть vault-выходы + create_user
принимает username и НЕ принимает password; имя сервиса нигде не проверяется;
- templates/subresource.go: поле модели + Computed/Sensitive атрибут password,
чтение Vault родителя в Create (GetInstanceStateDetails + GetInstanceVaultSecrets)
и перенос уже полученного пароля в Update (чтобы Computed-атрибут не стал unknown);
- resources_core/subresource_user_password.go: ExtractUserPassword — разбор
{"<username>":{"password":"..."}} с безопасным возвратом пустой строки;
- writers: регрессионный тест «фича включена/выключена».
Проверено генерацией и сборкой test-стенда: выход получили 4 подресурса
(postgres_user, kafka_user, clickhouse_user, mongodb_user); mariadb_user НЕ затронут
(там пароль входной); k8s_*_user и vc_org_user не затронуты (пользователь
адресуется не через username). go test ./... — ok, go build — чисто.
Записал в ОБЩИЙ файл архитектуры (TOOLS/ARCHITECTURE.md, PRIMARY SOURCE OF TRUTH):
- раздел «Subresource-born secrets» в Subresource Resources — проблема, принцип,
правило «service-specific DATA, never logic», факт postgres vs mariadb;
- пункт 3 в Exception Registry — как объявлять признак в YAML-спеке и прокидывать
через types.go + loader.go, без svc.Name == "..." в шаблоне.
В provider_philosophy.md оставлена короткая ссылка на ARCHITECTURE.md (источник один).
В раздел 6 (Подресурсы) добавлен подраздел про секреты, рождаемые операцией
подресурса:
- проблема: vault_secrets родителя — Computed, обновляется только в Read, поэтому
после create_user пароль недоступен в том же apply (Invalid index);
- принцип: пароль должен быть выходом самого подресурса, не читаться из родителя;
- как привязано к данным, а не хардкодом: признак в YAML-спеке (по аналогии с
suspend_on_destroy_default), условный блок в общем шаблоне;
- факт из спеков: postgres = пароль генерит платформа (нужен выход), mariadb =
пароль задаёт пользователь на входе (выход не нужен).
README читает человек впервые — ему нужны структура, шаги запуска и операции,
а не разбор прошлых костылей. Удалено:
- раздел «Почему нельзя создать всё одним apply» с историей про try() и PGPASSWORD;
- упоминания try() в apps/lucee.tf, apps/flask.tf, apps/nodejs.tf;
- «data-source/backend» из apps/locals.tf и путь к удалённому разделу из pg/outputs.tf.
Заодно удалён старый TEST_STAND/CRUD/terraform.tfvars (не читается, значения
перенесены в pg/terraform.tfvars и apps/terraform.tfvars).
Проверено: terraform validate — Success в pg/ и apps/ (apps — с временным creds.json).
Было: одна папка, один state — destroy убивал и БД, и приложения; пароль БД
приходилось вытаскивать костылём try() в одном apply, приложения поднимались
с пустым PGPASSWORD.
Стало:
- pg/ — кластер PostgreSQL + пользователь + база + outputs (хост/порт/юзер/база/пароль);
destroy здесь переводит кластер в Suspend, а пользователь и база не удаляются
(keep_on_destroy = true + adopt_existing_on_create = true);
- apps/ — три приложения-потребителя; креды БД читаются из creds.json (выгрузка
outputs папки pg/, т.к. state раздельные, а data-source у провайдера нет);
try() убран полностью — пароль к моменту этого apply уже существует;
- apps/.gitignore — creds.json, terraform.tfvars, state/lock;
- README.md переписан: структура, «зачем разделено», пошаговые 3 шага запуска,
повседневные операции (destroy приложений не трогает БД), про destroy базы.
Проверено: terraform init+validate в обеих папках — Success;
plan в pg/ — 3 to add (кластер, пользователь, база) + 6 outputs.
- VERSIONS.md: три строки обновлены, добавлены первые 16 символов sha256 каждой сборки;
- HISTORY: что заливалось, как проверялось (схема 60/62 ресурсов, исключения —
action-шаблон mongodb_rollback и рукописный service_operation), грабли
checksum mismatch при той же версии + лечение, и найденный факт: state
TEST_STAND/CRUD пуст (serial 38), инстансы в облаке помечены deleted.
Инстанс PG при destroy уходит в Suspend (suspend_on_destroy_default: true в
90_postgres.yaml), а не удаляется. Без keep_on_destroy подресурсы (create_user/
create_database) удалялись бы из живого кластера — после resume приложения
работали бы с пустой БД, данные базы были бы потеряны.
keep_on_destroy=true → режим state_only: при destroy подресурс остаётся в облаке
и только убирается из state. В паре с adopt_existing_on_create=true следующий
apply усыновляет существующий объект, а не падает на 'уже существует'.
Проверено: terraform validate — Success (провайдером 3.0.0, где атрибут есть).
Проверяет три части фичи в сгенерированном коде:
1) поле модели KeepOnDestroy с тэгом tfsdk:keep_on_destroy;
2) атрибут схемы Optional + Default=false (поведение по умолчанию не меняется);
3) в Delete проверка флага идёт РАНЬШЕ вызова операции удаления — иначе destroy
всё равно удалял бы объект в облаке.
Вывод генератора перед сравнением нормализуется по пробелам: gofmt выравнивает
поля структур и ключи map, из-за чего поиск подстроки «как в шаблоне» не работает.
Запуск: cd TOOLS/resource-generator && go test ./internal/writers/... — ok.
- у подресурсов появился раздел «Поведение при destroy» с таблицей флагов
(keep_on_destroy / skip_missing_on_delete / adopt_existing_on_create) и предупреждением
про расхождение state и облака;
- в блоке destroy у инстансовых ресурсов добавлен keep_on_destroy (раньше не документировался
вообще ни на одной странице);
- в types добавлено поле Lifecycle.KeepOnDestroyDefault.
Проверено генерацией: keep_on_destroy упоминается на 49 страницах test-стенда,
включая postgres_user.md (подресурс) и postgres_params_create.md (инстанс).
Подресурсы (nubes_postgres_user/database и остальные 20) удалялись всегда, даже когда
родительский инстанс при destroy только приостанавливается. Из-за этого пользователь БД
удалялся, а следующий apply создавал его заново с НОВЫМ паролем.
Добавлен атрибут keep_on_destroy (как у инстансовых ресурсов, Default=false):
- поле KeepOnDestroy в модели;
- атрибут схемы (Optional+Computed, Default=false);
- ранний выход в Delete с предупреждением (режим state_only).
Проверено: 22 подресурса получили атрибут; сборка провайдера с перегенерённым кодом — BUILD_OK.
Дефолт false → поведение существующих конфигураций не меняется.
Новая страница docs/curated/crud/three_apps.md (раздел «Проверенные примеры» в mkdocs.yml):
- что создаётся (6 ресурсов: PG + user + db + Lucee + Flask + Node.js);
- ссылки на git: gitea.services.ngcloud.ru/terraform/{tfluceecrud,tfflaskcrud,tfnodejscrud}
(проверено HTTP 200), в манифестах — lucee_git_path/flask_git_path/nodejs_git_path;
- запуск: два apply и почему (пароль появляется только после create_user);
- доступ к БД: vault_secrets["users"] -> { "<username>": { "password" } }, и ловушка
state_out.users (метаданные без пароля);
- особенности: adopt_existing_on_create, уникальные домены, camelCase в postgres_conf, realm;
- диагностика: ошибку смотреть в stages операции, а не в errorLog.
Проверено локальной сборкой mkdocs: страница собирается, битых ссылок нет,
все три ссылки на репозитории присутствуют в HTML.
Раньше locals читали пароль напрямую: jsondecode(vault_secrets["users"]).user4crudpg.password.
При первом apply пароля ещё нет (create_user выполняется после создания кластера), поэтому
Terraform падал с «Invalid index ... does not identify an element in this collection value».
Теперь через try(... = ""): на первом apply в env идёт пустая строка и прогон не роняет;
на втором apply пароль уже в Vault, try возвращает настоящее значение, приложения получают верный env.
Комментарии в lucee.tf/flask.tf/nodejs.tf объясняют зачем try и почему два apply.
Проверено: terraform validate — Success; plan — No changes; Exit 0.
Проверено по API 2026-10-01 (pg4crud2, TEST):
GET /instances/<uid>/vault/users -> {"users":{"user4crudpg":{"password":"..."}}}.
Пароль ЕСТЬ; state.out.users — метаданные без пароля (их легко перепутать).
- README.md: строка навигации «Пароль БД / секреты Vault» + раздел «Грабли, на которые уже наступали»
(Invalid index из-за одного apply; errorLog врёт — смотреть stages; лишний sensitive).
- docs/curated/postgres/pg_user_db.md: раздел «Пароль пользователя БД и секреты Vault» (ловушки,
два apply, диагностика через /instanceOperations?fields=stages); исправлено утверждение «все 4 ресурса
за один apply» — для приложений, читающих пароль, нужен второй apply.
- docs/30_registry/guides/getting-started.md: помечены устаревшие ключи adminUser/adminPass (сейчас 404).
- HISTORY/2026-10-01_...: дополнение с фактами и указанием, что первый разбор ошибся.
Зафиксировано по журналу операции 181D3B1D (GET /instanceOperations/<uid>?fields=stages):
падение на шаге «1. Валидация» → «Проверка ёмкости рес платформы»:
«Невозможно развернуть приложение в данной ресурсной платформе».
errorLog «Invalid JSON String» сути не отражает.
Отдельно отмечено, что не доказано (snake_case в postgres_conf, причины операций
4D60A0B6 и 5AAF1E39 — их stages недоступны, API отдаёт 404) и что моё утверждение
в коммите e3182c3 было предположением, выданным за факт.
Провайдер отправляет postgres_conf на платформу как есть (resources_core.FormatString
возвращает строку без перевода имён), поэтому ключи обязаны совпадать со спекой:
postgresConf.paramName / postgresConf.paramValue. С snake_case (param_name/param_value)
платформа падала с "Invalid JSON String" (операция 5AAF1E39-8812-4994-AD14-78D51ED2077D).
Значение paramValue взято '' — как в HAR/pgmodify.har и в TEST_STAND/PG/resources.tf.
План проходит: 6 to add, exit 0.
Из-за sensitive = true в plan вместо значений печаталось "(sensitive value)".
Убрано в: DEV_STAND/CRUD, DEV_STAND/POSTGRES, TEST_STAND/POSTGRES, TEST_STAND/PGwNewRegistry.
api_token остаётся sensitive везде — он действительно секрет.
realm — не секрет, но из-за sensitive = true в plan вместо имени печаталось
"(sensitive value)". Теперь видно resource_realm = "k8s-3-sandbox-nubes-ru".
Плана это не меняло: plan по-прежнему 6 to add, exit 0.
Прочие sensitive оставлены как есть: api_token (секрет), vault_secrets (платформа).
- lucee/flask/nodejs: добавлен adopt_existing_on_create = true (усыновлять существующий
инстанс вместо падения с «ресурс с таким именем уже существует»)
- удалены git_revision и одноимённые locals (в TEST их нет)
- git_path: Nail -> terraform (проверено по HTTP: /Nail/<repo> отдаёт 301 на /terraform/<repo>)
- terraform.tfvars.example: комментарий s3_user_uid = UUID S3-пользователя
Имена ресурсов и домены оставлены dev-своими (уникальными). realm dev = k8s-3-sandbox-nubes-ru.
Проверка API dev-стенда (/instances?isDeleted=false): 9 инстансов, ни одного под сервисы
89 flask / 94 lucee / 95 nodejs и PostgreSQL; поиск crud|pg4|lucee|flask|nodejs -> 0. Коллизий нет.
НЕ исправлено (не моя правка, есть и в HEAD): terraform validate падает на nubes_nodejs.json_env —
в спеке dev-стенда у сервиса 95 объявлен обязательный sub_param DB_PASS, поэтому схема требует
объект { db_pass }, а конфигурация передаёт строку jsonencode().
vm.tf целиком обёрнут в блочный комментарий /* … */ со пояснением причины:
в test инстанс vApp не прошёл валидацию схемы (нужен reconcile). Вернуть —
удалить обрамляющие строки.
Проверено: terraform fmt -check OK, validate Success,
plan = 1 to add (только Штурвал); инстансов vApp/ВМ стенда в тенанте нет (все deleted).
Первый apply в test: vdc/edge/org_ip/snat создались; упали:
- Штурвал: 'свободных Ip в тенанте WZ03709-iaas: 1, необходимо 2' — на NaeelOrg
было count=10, часть адресов держит кластер iot-naeel. Поднято до 12.
- vApp: 'не удалось валидировать схему инстанса' -> not created (вероятно плавающая,
при повторе — reconcile).
После destroy (владелец): fullpipe-vdc = suspended (suspend_on_destroy),
fullpipe-edge = running (keep_on_destroy), локальный state пуст.
Порядок: apply -target=nubes_vc_org_ip_allocation.org_ip -> полный apply.
HISTORY/2026-10-01_test_stand_fpipegmail.md дополнен разделом с ошибками и решением.
Создана папка (без .terraform/state/lock — это состояние dev). Изменены параметры:
- versions.tf: nubes-dev/nubes 2.0.1 -> nubes-test/nubes 3.0.0;
- variables.tf: api_endpoint -> lk-api-gateway-test.ngcloud.ru;
- terraform.tfvars: organization=NaeelOrg (найдена через API, svc 19), ip_count=10
(в test на орге уже выделено 10 IP), storage SSD (в test vDC строят на SSD);
- shturval.tf: shturval-test1 / shturval-test-01 / workers-shturval-test.
Коллизии проверены: в test заняты naeel-vdc, 'VDC для кластера iot-naeel',
naeel_vc_nsxt, 'Edge для кластера IOT naeel', 'Кластер Kubernetes [iot-naeel]' —
наши имена (fullpipe-vdc/-edge/-vapp-02, web02, shturval-test1) свободны.
Проверено: terraform init (3.0.0), fmt -check OK, validate Success,
plan = 7 to add / 0 change / 0 destroy. apply НЕ запускался.
Документация: HISTORY/2026-10-01_test_stand_fpipegmail.md
Полный цикл 03 (01 YAML -> 02 Go/доки -> сборка 3 платформ -> GPG -> S3) по каждому стенду
начиная с YAML. Профиль dev: VERSION 2.0.1 -> 2.0.0 (db9d93e).
Проверено: sha256 залитого linux-бинарника == локальной сборке на всех трёх
(prod 9c20e0a7, test 9cdfa8b8, dev 86c667f7); по 5 объектов на версию; YAML 36/36/40.
Отличие от заливки 30.09: теперь в сборки вошли 8 коммитов правок ядра/генераторов
(core, resources_core, resource-generator, check_schema_names + вызов в 03).
Документация: HISTORY/2026-10-01_release_x_0_0_all_stands.md, VERSIONS.md.
jlib.tofu не смог зарезолвить provider vmware/vcd через terraform-mirror.yandexcloud.net:
'internal DNS 169.254.25.10:53: server misbehaving' -> 'Edge не удалось найти в Cloud Director'
(операция не выполнилась). Проверено извне: зеркало доступно (DNS резолвится, index.json HTTP 200,
0.88s) => проблема во внутреннем DNS/сети платформы, не в зеркале.
Ошибка модификации Edge nsx_WZ03709-saas-tbxiw8kt: FORBIDDEN 'Cannot disable load
balancer ... since there are Pools'. Пулы остались от неудалённых CAPvcd/Штурвала;
пока они есть — ALB не отключить и Edge не удалить. Клиентских путей нет,
нужна платформа (заявка расширена: CAPvcd + LB Pools + затем Edge).
Владельцу не удаётся удалить Edge: платформа блокирует из-за инстансов CAPvcd
(shturval-dev-01), хотя кластер удалён из ЛК 25.09.
Установлено (API dev): shturval-dev1 (svc 150, uid 05ae1dbc-…) — deleted, операций нет;
тенанта WZ03709-saas в dev нет (единственная организация — kontra).
Попытка доудаления (по указанию владельца):
POST /instanceOperations (svcOperationId=109, delete) -> 201, run -> 201,
результат: isSuccessful=false, errorLog="Cannot invoke \"String.length()\" because
\"text\" is null" — NPE бэкенда. Остатки CAPvcd не вычищены.
Вывод: только техподдержка (MAN vc_org прямо это предписывает).
Инцидент 2026-09-30 показал: невалидное имя атрибута (s3-inst) проходило генерацию,
сборку и заливку, а ломалось только у пользователя (Terraform отвергает схему целиком).
- TOOLS/scripts/check_schema_names.sh: проверяет все tfsdk:"..." в сгенерированном Go
на [a-z0-9_]; exit 1 при нарушении, с подсказкой про helpers.ToSnake.
- 03_build_and_upload_provider.sh: вызов стража после 02 (до сборки и заливки).
- ARCHITECTURE.md: страж добавлен в список enforced-скриптов.
- HISTORY: пункт 'не закрыто' заменён на 'закрыто' с проверками.
Проверено: dev/test/prod -> OK; искусственный пример (tfsdk:"s3-inst") -> exit 1.
Инцидент: в 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).
Файл ВМ включён в конфигурацию (был .tf1 — Terraform его не читал).
Дефолты переименованы, т.к. инстансы со старыми именами есть в облаке,
сломаны и не удаляются:
- vapp_resource_name: fullpipe-vapp -> fullpipe-vapp-02
- vapp_name: fullpipe-vapp-01 -> fullpipe-vapp-02
- vm_resource_name: fullpipe-vm-01 -> fullpipe-vm-02
- vm_name: web01 -> web02
Проверено: terraform validate -> Success (в DEV_STAND/FPipeGmail).
Цикл 03 (01+02 -> сборка linux/windows/darwin -> SHA256SUMS -> GPG -> S3) по dev.
Версия 2.0.1 (ранее удалена при чистке, создана заново).
Проверено:
- sha256 локальной сборки == SHA256SUMS (linux/amd64, 13 172 824 B);
- GET /v1/providers/nubes-dev/nubes/versions -> содержит 2.0.1;
- download linux/amd64 2.0.1 -> HTTP 200;
- в S3 5 объектов (3 zip + SHA256SUMS + .sig), 37.92 MiB.
test и prod не перезаливались (правки ядра туда не включены).
Документация: VERSIONS.md, HISTORY/2026-09-30_dev_release_2_0_1.md.
Код-ревью (раунд 5), п.1/6: pre-check брал схему из GET /instanceOperations/default/{opId},
а payload строился по живой схеме ?fields=cfsParams — два источника. default может
расходиться с живой => риск ложного пропуска modify.
Решение: pre-check вообще не запрашивает схему.
- modifierDesiredEqualsLive(ctx, uid, desired): сравнение по live-кодам
(live[lower(code)]), единственный источник — state.params.
- Значения: похожи на JSON ({/[) — смысловое сравнение; иначе скалярное с
нормализацией (null/"" -> ""; true/false без учёта регистра) — закрывает и
регистр bool.
- Fail-safe сохранён: пусто/нет кода/ошибка live => modify выполняется.
- Удалены: fetchOperationSchemaByID, modifierValuesEqual, lookupLiveParam больше
не участвует в pre-check (остаётся для досылки).
- Тесты переписаны (RawValuesEqual_Scalars/JSON, DesiredEqualsLive: 4 кейса).
Документация: TOOLS/ARCHITECTURE.md -> новый раздел «Modifier Idempotency»
(5 правил контракта); HISTORY — журнал раунда 5.
Проверено: go build ./... OK; go test ./internal/... -short PASS.
- Q1: POST не ретраится (не идемпотентен; Idempotency-Key у API нет) — решение.
- Q2: при ошибке после POST /instanceOperations и до run операция остаётся черновиком;
отмены нет (ни в коде, ни в HAR — DELETE /instanceOperations/{uid} отсутствует).
- Q4: единый контракт жизненного цикла — keep_on_destroy + suspend_on_destroy;
delete_strategy (YAML) = маппинг на них (noop_warn/inverse/error).
Проблема: CreateGenericInstanceUniversalV6 при ЛЮБОЙ ошибке после создания инстанса
возвращал "", а шаблон Create при ошибке не писал ID в state => облачный инстанс
осиротевал (Terraform о нём не знает, повторный apply упирается в страж дубликатов).
- core/instance_create.go: ошибки после получения instanceUid возвращают uid вместе
с ошибкой (POST /instanceOperations, пустой opUid, разбор cfsParams, resolve,
отправка параметров, validate, run, waitForOperationFinish, ensureInstanceCreated).
До создания uid — по-прежнему "".
- templates/instance.go: при err != nil и id != "" -> data.ID + resp.State.Set (partial
state), затем AddError.
- client_test.go: TestCreateGenericInstance_KeepsUIDWhenOperationCreateFails,
TestCreateGenericInstance_EmptyUIDWhenInstanceCreateFails.
- ARCHITECTURE.md: пункт про partial state.
Проверено: 02 (dev) + dev-materialize -> 40 файлов resources_gen содержат фикс;
go build ./... OK; go test ./internal/... -short PASS.
Замер по generated/dev/resources_yaml (40 файлов, только чтение):
- required-параметров: 852; с пустым data_type — 5;
- всего с пустым data_type: 12 (~1.2%); угадывание по имени даёт != '' только
для 1 тестового (1_dummy.jsonExample) => гипотеза A4 не подтверждается,
правка косметическая, не исправление дефекта.
Repinoid