IoT MVP: архитектура, план реализации, лог рассуждений

- Определена архитектура managed IoT service
- Согласовано решение: RabbitMQ (MVP), потом Kafka; EMQX + CRD контроллер
- Создан подробный план для Sonnet (doc/iot-mvp-plan.md)
- Добавлено правило в copilot-instructions: лог мышления в doc/thinking/ по датам
- Полный ход рассуждений в doc/thinking/2026-04-04.md

Ключевые решения:
- IoT код в iot/ (легко вынести потом)
- CRD IoTDevice + контроллер (как все остальное в sless)
- EMQX HTTP Auth Backend для динамической аутентификации устройств
- Архитектура broker-agnostic (легко переключить на Kafka)
- Terraform: расширяем текущий provider (sless_iot_device ресурс)
This commit is contained in:
Repinoid
2026-04-04 08:34:14 +03:00
parent ebbba66146
commit 6dc2dc69ba
24 changed files with 2958 additions and 51 deletions
+54 -3
View File
@@ -221,6 +221,56 @@ Error: Ошибка клиента
---
## 3.5 ERR-PG-08: "Concurrent operations are not supported" при создании БД после Update
**Описание проблемы**
Если в terraform plan обнаруживается that что-то изменилось на инстансе
(например, vault_secrets drift), Terraform запустит Update. После успешного
завершения Update, попытка создать зависимые ресурсы (БД, пользователей)
немедленно падает с ошибкой 422:
```
Error: Ошибка клиента
ошибка API 422: {
"TITLE": "Concurrent operations are not supported (job status: SUCCESS)"
}
```
**Когда воспроизводится**
- При повторном `terraform apply` (vault_secrets обновляется каждый раз)
- При создании БД сразу после Update (даже в одном apply)
**Попытка обхода**: Ожидание между apply'ами (10s, 60s, 120s) **НЕ ПОМОГАЕТ**.
Ошибка 422 возникает независимо от временной задержки.
**Причина**
Nubes API имеет встроенный serial operation lock на инстанс. Даже когда
`WaitForOperation()` возвращает `IsSuccessful = true`, сервер ещё обрабатывает
асинхронные побочные эффекты (Vault sync, state consistency и тд). Новые
операции отклоняются до полного завершения обработки.
**Текущий workaround**
Разбить apply на несколько фаз:
```hcl
# Фаза 1: postgres.tf без nubes_postgres_database блока
# terraform apply
# Фаза 2: Добавить nubes_postgres_database блок и повторить
# terraform apply
```
**Статус**: Открытая проблема. Требует fix в `internal/provider/client_impl.go`
(добавить post-completion delay или retry mechanism).
**Документация см.**: [ERR-PG-08-concurrent-operations.md](../ERR-PG-08-concurrent-operations.md)
---
## 4. Последовательность зависимостей (обязательная)
Нарушение любого из `depends_on` в цепочке вызывает ошибки API.
@@ -284,12 +334,13 @@ ssh user@vm "tmux attach -t tf"
| Создание `nubes_postgres_user` с `ddl_user` | ✅ | ~60–90 сек | — |
| Создание `nubes_postgres_user` с `app_user` | ❌ | Секрет не создан (~3 мин) | Только `ddl_user` |
| Параллельное создание нескольких users | ❌ | Race condition в Vault | `depends_on` chain |
| Создание 2-го пользователя (любого) | ❌ | Vault: Секрет не создан (~3–4 мин) | Ограничение тест-окружения |
| Создание 2–3-го пользователя (любого) | ✅ | ~60–90 сек каждый | `depends_on` chain обязателен |
| Удаление `nubes_postgres_user` | ✅ | ~56–81 сек | — |
| Принятие существующего user (`adopt`) | ✅ | не работает при "зависшей" операции | Новое имя |
| Создание `nubes_postgres_database` | ✅ | ~47–66 сек | — |
| Создание `nubes_postgres_database` | ⚠️ | Может блокироваться ERR-PG-08 | См. раздел 3.5 |
| Удаление `nubes_postgres_database` | ✅ | ~46–92 сек | — |
| Повторный apply (idempotent) | ❌ частично | `vault_secrets` → destroy+recreate user/db | Открытая проблема |
| Update инстанса + создание БД (одновременно) | ❌ ERR-PG-08 | "Concurrent operations are not supported" | Разбить на фазы или использовать retry |
| Повторный apply (idempotent) | ❌ частично | Комбинация ERR-PG-02 (исправлена) + ERR-PG-08 | Workaround: раздельные apply |
| apply через SSH (долгий) | ❌ | SSH timeout убивает процесс | `nohup` или `tmux` |
---