docs(history): раскладка HISTORY по тематическим папкам (75 файлов)

Было: 41 файл в корне HISTORY/ + авторские папки OPUS/ и SONNET/ (34 файла).
Стало — тематическая нумерация в стиле NOTES/ (10_, 20_, …):

  10_reviews/    ревью кода и разборы от LLM (2)
  20_releases/   заливки версий в реестр, чистки реестра, нумерация версий (8)
  30_provider/   ядро провайдера: архитектура, модификаторы, UUID, nested (6)
  40_generator/  генератор YAML/спеки, формат MAN (3)
  50_docs/       пайплайн документации, навигация, публикация, хостинг S3 (9)
  60_stands/     стенды и примеры: CRUD, FullPipe, Штурвал, TEST_STAND (7)
  70_infra/      реестр, API Gateway, DDoS-Guard, VPN/213, зеркала (4)
  90_llm/        диалоги и промпты с LLM вне тематики: OPUS/, SONNET/, gemini/ (34)

OPUS/ и SONNET/ перенесены как есть в 90_llm/ — чтобы не рвать пары
«бриф → ответ» внутри диалогов. Все переносы — через git mv (история сохранена).
Перед правкой: TMP/backup_2026-10-02/HISTORY_before_restructure.tar.gz.
Перекрёстные ссылки обновляются следующим коммитом.
This commit is contained in:
Repinoid
2026-10-02 07:35:32 +03:00
parent 9cc7b3f260
commit 2c196e8cc8
75 changed files with 0 additions and 0 deletions
@@ -0,0 +1,178 @@
# 2026-07-06 — Архитектурный рефакторинг tf_provider
## Контекст
После анализа Claude Opus (`HISTORY/OPUS/2026-07-06_architectural_analysis.md`) выявлены архитектурные проблемы и выполнены исправления.
## Выполненные изменения
### 1. Реструктуризация проекта
```
Было: Стало:
devops/ TOOLS/scripts/ (все .sh)
devops/profiles/ TOOLS/config/ (profile.env, services_list, timeouts)
devops/ARCHITECTURE.md TOOLS/ARCHITECTURE.md
devops/config/ УДАЛЕНО (дубликат profiles)
provider/resources_yaml/ УДАЛЕНО (сгенерированное → generated/)
provider/internal/resources_gen/ УДАЛЕНО (сгенерированное → generated/)
generated/{test,prod,dev}/ (вывод пайплайна)
```
### 2. Независимость генераторов
- `yaml-generator` — требует `NUBES_OUTPUT_DIR`, без default в `provider/`
- `resource-generator` — требует `NUBES_RESOURCES_DIR` + `NUBES_RESOURCES_GEN_DIR`
- `docs-generator` — требует `--resources`, `--docs`, `--version` флаги
- Удалён `detectVersion()` — больше не читает `provider/main.go`
- Удалён `detectRoot()`, `pickPath()` — нет хардкод-путей
### 3. Общая библиотека типов
Создан `TOOLS/lib/` — единый YAML-контракт. Модуль: `tf-tools/lib`.
Подключены:
- `yaml-generator` → type alias `ParamSpec = lib.ParamSpec` и др.
- `resource-generator` → type alias `OutputParam`, `OperationSpec`, `ParamSpec`
НЕ подключён:
- `docs-generator` — будет заменён на LLM-генератор, не трогаем
При добавлении поля в YAML — править `lib/types.go`, несогласованность ловится компилятором.
### 4. Синхронизация версий
- `provider/main.go`: 5.0.75 → 5.0.60 (соответствует последней сборке)
- `profile.env`: три переменные → одна `VERSION`
- `03_build`, `04_publish`: `${PROVIDER_VERSION:-${RELEASE_VERSION:-}}` → `${VERSION}`
### 5. Автосборка бинарников
`01_generate_yamls.sh`: если исходники новее бинарника — пересборка.
### 6. Удалённый мусор
- `devops/config/` — дубликат profiles
- `02_generate_resources_and_docs.sh` + `_template.sh` — legacy, заменены v2
- `cloud-dashboard/`, `tools/` (root), `internal/` (root), `universal_rebuild/`
- 18 одноразовых файлов (check_ops.py, s.sh, ...)
### 7. Слияние ops-generator → docs-generator
`--ops` флаг. Три генератора вместо четырёх.
### 8. Документация LLM
`docs/LLM_DOCS_GENERATION.md` — подход, промпт, тест на Postgres (gpt-oss-120b, 9/10).
## Текущее состояние
```
tf_provider/
├── TOOLS/ — всё для генерации (код + скрипты + настройки)
│ ├── yaml-generator/
│ ├── resource-generator/
│ ├── docs-generator/
│ ├── lib/ — общие YAML-типы
│ ├── scripts/
│ ├── config/{test,prod,dev}/
│ └── ARCHITECTURE.md
├── provider/ — только исходники
├── generated/ — вывод пайплайна (gitignored)
└── docs/ — документация
```
## Осталось
- [x] yaml-generator → lib
- [ ] resource-generator → lib
- [ ] docs-generator → lib
---
## ⚠️ BUG: modify падает с 500 — GET ?fields=cfsParams вызывает getResourceRealmConfig
**Симптом:** `terraform apply` при modify возвращает:
```
не удалось получить детали операции: ошибка API 500: Invalid call of the function [getResourceRealmConfig], first Argument [resourceRealm] is of invalid type, Cannot cast Object type [Struct] to a value of type [string]
```
**Причина:** `RunInstanceOperationUniversalWithDefaults` (client.go:384) делает GET `/instanceOperations/{opUid}?fields=cfsParams`. Бэкенд (ColdFusion) при вычислении cfsParams вызывает `getResourceRealmConfig` через `expression_parser.cfc:184`. Если `resourceRealm` в контексте инстанса — Struct (объект), а не string, функция падает.
**Где проявляется:**
- `client.go:420` — `RunInstanceOperationUniversalWithDefaults` (modify/create/delete с дефолтами)
- `client.go:1399` — `RunInstanceOperationUniversalByCode` (операции по code)
- `client.go:224` — `CreateGenericInstanceUniversalV6` (CREATE flow) — работает на новых инстансах
**Почему на одних инстансах падает, на других нет:**
- Новые инстансы: `resourceRealm` = string → OK
- Старые/модифицированные: `resourceRealm` = Struct → 500
**Исправление (v5.0.62):**
- `crud.go:58`: `UpdateResourceWithTimeout` → `RunInstanceOperationUniversal` (без GET)
- GET не нужен для modify — все параметры уже известны из конфига
**Статус:** ✅ FIXED v5.0.62
**Файлы:**
- `/home/naeel/tf_provider/provider/internal/resources_core/crud.go:58`
- `/home/naeel/tf_provider/provider/internal/core/client.go:384` (WithDefaults — не используется в modify)
**Тесты (v5.0.62):**
- ✅ CREATE postgres — OK
- ✅ MODIFY postgres (replicas, backup_config, access_config) — OK
- ✅ CREATE/DELETE user — OK
- ✅ CREATE/DELETE database — OK
- ✅ Invalid role → 400 c понятным сообщением — OK
- ✅ No-change plan (идемпотентность) — OK
**Остаётся риск:**
- `RunInstanceOperationUniversalByCode` (client.go:1399) всё ещё делает GET — может упасть для service_operation_resource на проблемных инстансах
- `CreateGenericInstanceUniversalV6` (client.go:224) — CREATE на инстансах где resourceRealm = Struct может упасть
---
## ⚠️ BUG: Параллельные операции на одном инстансе ломаются
**Симптом:** При создании нескольких subresource'ов (user, database) на одном postgres-инстансе:
- `ошибка API 500: Cannot connect to the orchestrator` — бэкенд не справляется с параллельными запросами
- `операция завершилась успешно, но объект не найден в state_out` — user создался, но RefreshResourceState не видит его
- `экземпляр не готов: операция в ожидании` — инстанс занят предыдущей операцией
**Причина:** Terraform по умолчанию параллелит до 10 ресурсов (`-parallelism=10`). Все операции на одном инстансе (5 user'ов + 7 database'ов) стартуют одновременно → гонка на бэкенде.
**Пример:** 2026-07-07 на инстансе `5111108D`:
- 5 user'ов создавались параллельно: user_2 ok, user_1+user_3 — orchestrator error, user_4+user_5 — state_out не найден
- 7 database'ов упали: инстанс не готов
**План исправления:** mutex map в провайдере (стандартный подход как в AWS/GCP провайдерах):
```go
// client.go — глобальная карта мьютексов
var instanceMutexes sync.Map // key: instanceUid
func (c *UniversalClient) lockInstance(instanceUid string) func() {
mu, _ := c.instanceMutexes.LoadOrStore(instanceUid, &sync.Mutex{})
mu.(*sync.Mutex).Lock()
return func() { mu.(*sync.Mutex).Unlock() }
}
```
Вызывать в каждом CRUD:
```go
unlock := client.lockInstance(instanceID)
defer unlock()
```
**Альтернативы (хуже):**
- `depends_on` цепочкой в конфиге — неудобно, требует ручной правки .tf
- `-parallelism=1` — замедляет ВСЕ ресурсы, не только subresource'ы
**Затрагивает:**
- Все subresource-операции (postgres_user, postgres_database, mariadb_user, clickhouse_user, etc.)
- Modify + delete на одном инстансе тоже могут столкнуться
**Статус:** ⚠️ OPEN — не исправлено
**Файлы для правки:**
- `/home/naeel/tf_provider/provider/internal/core/client.go` — добавить mutex map + lockInstance
- `/home/naeel/tf_provider/provider/internal/resources_core/crud.go` — добавить lock/unlock в Create/Update/Delete
- `/home/naeel/tf_provider/provider/internal/resources_core/service_operation_resource.go` — добавить lock/unlock