terraform/tf_provider
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(arch): принцип секретов подресурсов — в TOOLS/ARCHITECTURE.md

Browse Source 
Записал в ОБЩИЙ файл архитектуры (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 (источник один).
This commit is contained in:
Repinoid
2026-10-01 17:08:30 +03:00
parent 57e7d4d077
commit 1a049efa44
2 changed files with 33 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/60_strategy/provider_philosophy.md
+2 -35
View File
@@ -48,41 +48,8 @@ To prevent "bad applies" and incomplete infrastructure states, the provider will
- Изменение ключевых параметров подресурса => ресурс заменяется.
- Это соответствует возможностям API и сохраняет корректность состояния Terraform.
### Секреты, рождаемые операцией подресурса (принцип и практика)
**Проблема (наблюдаемая, 2026-10-01):** у части сервисов секрет (пароль пользователя
БД) **генерируется платформой** внутри операции `create_user`, а доступен он не в
выходе подресурса, а в `vault_secrets` **родительского инстанса**. При этом
`vault_secrets` родителя — `Computed`-атрибут, который обновляется только в `Read`
родителя (перечитывание облака на refresh/повторном apply), а **не** в конце
`Create` подресурса. Следствие: внутри одного `apply` после `create_user` пароль
нельзя прочитать — `vault_secrets["users"]` ещё пуст, и обращение к нему даёт
`Invalid index`.
**Принцип (правило для генератора):** секрет, который порождает операция
подресурса, должен становиться **выходом самого подресурса** сразу по завершении
его `Create`, а не читаться потребителем из родителя. Потребитель берёт пароль
из `nubes_<svc>_<sub>.<sub>.password`, и зависимость по графу Терраформа
автоматически разносит создание по времени.
**Как это «прописано для postgres», а не хардкод в шаблоне.** В общий шаблон
подресурса (`TOOLS/resource-generator/internal/templates/subresource.go`) НЕ
зашивается имя сервиса. Признак «у этого подресурса-пользователя пароль
генерируется платформой» должен приходить из **данных спека** (YAML), как уже
сделано для `suspend_on_destroy_default` / `adopt_existing_on_create_default`
(раздел 7). В шаблоне появится условный блок, срабатывающий только при наличии
этого признака.
**Различия сервисов (факт из спеков):**
| Сервис | Пароль пользователя | Что нужно |
|---|---|---|
| PostgreSQL (90) | генерирует платформа → `vault_secrets["users"]` | выход пароля у `postgres_user` из Vault по завершении `create_user` |
| MariaDB (115) | задаёт САМ пользователь (входной параметр `password` в `create_user`) | ничего — пароль уже в манифесте, `nubes_mariadb_user.x.password` |
Вывод: фича «выход пароля» нужна только подресурсам, у которых `create_user`
**не** принимает пароль на входе (то есть где он auto-generated). Хардкодить
перечень сервисов в шаблоне запрещено — признак декларируется в YAML-спеке сервиса.
> Секреты, рождаемые операцией подресурса (пароль пользователя, авто-генерируемый
> в `create_user`), описаны в `TOOLS/ARCHITECTURE.md` → «Subresource-born secrets».
## 7. Каноничная lifecycle-логика для сервисов с suspend/resume