chore: update ignore rules

- services/funcs: новые маршруты POST create-function, POST save-function,
  DELETE delete-function — создание/редактирование/удаление через браузер
- index.html: модалка создания с шаблонами Python/Node.js hello world,
  кнопки edit/delete на каждой карточке функции
- sless-funcs-service:v0.1.4 задеплоен
- examples/POSTGRES: удалены логи, .bak, backup tfstate, лишние функции
  оставлены 2 Python (pg-stats, pg-counter) + 2 Node.js (pg-info, js-idempotent)

.github/copilot-instructions.md

@@ -4,18 +4,6 @@
 
 **НЕ "СОВЕРШЕНСТВОВАТЬ" РАБОЧИЙ КОД БЕЗ ЯВНОГО УКАЗАНИЯ.**
 
----
-
-## ЗАПРЕТ НА ВЫДУМКИ
-
-**КАТЕГОРИЧЕСКИ ЗАПРЕЩАЕТСЯ придумывать, догадываться или предполагать:**
-- значения параметров, которые не видны в коде или документации
-- допустимые значения enum/ролей/типов — если не взяты из реального источника
-- поведение API, провайдеров, библиотек — если не подтверждено кодом или документацией
-- любые факты о системе, которые агент "знает" из общих соображений
-
-**Если информации нет — спросить у пользователя. Не угадывать.**
-
 Если код работает — не трогать. Никаких:
 - рефакторингов "попутно"
 - улучшений стиля
@@ -72,20 +60,6 @@
 
 ---
 
-## Лог мышления (обязательно)
-
-Каждый агент в каждом чате **обязан** вести лог своих рассуждений:
-- Папка: `doc/thinking/`
-- Файл: `ГГГГ-ММ-ДД.md` (по дате сессии)
-- В начале файла указать имя агента и модель
-- Если файл на текущую дату уже существует — дописывать в конец, добавив разделитель `---` и имя агента
-- Записывать **полный** ход мыслей: что анализирую, какие гипотезы, что нашёл, что отбросил, к чему пришёл, почему
-- Записывать **до** начала действий (план) и **после** (результат)
-
-Цель: пользователь должен видеть весь процесс рассуждений в читаемом виде.
-
----
-
 ## Git
 
 Коммитить и пушить после каждого завершённого этапа.

.gitignore

@@ -69,12 +69,9 @@ event-dispatcher
 # build artifacts
 /sless
 examples/POSTGRES/stress_log*.txt
-examples/VM/vm_key
-examples/VM/vm_key.pub
 /deployments/k8s/operator-demo.yaml
 /doc/decisions/log.md
 /doc/log.md
 /s3cfg_registry
 /sqs-operator/quick_test.sh
 /sqs-operator/sqs_load_test.sh
-/.s3cfg_registry

deployments/k8s/emqx.yaml

@@ -1,167 +0,0 @@
-# Создано: 2026-04-04
-# EMQX MQTT-брокер для IoT-сервиса (namespace: sless).
-#
-# Архитектура:
-#   IoT Device → MQTT CONNECT → EMQX (HTTP auth → sless-operator:9090/internal/mqtt/auth)
-#   EMQX → MQTT PUBLISH → sless-iot-bridge (paho subscriber) → RabbitMQ queue iot.{ns}.telemetry
-#   RabbitMQ → event-dispatcher → serverless function
-#
-# EMQX 5.x конфиг через emqx.conf (HOCON формат), монтируется как ConfigMap volume.
-# НЕ используем env vars для конфигурации EMQX 5.x — они не поддерживаются аналогично 4.x.
-#
-# Порты:
-#   1883 — MQTT (plaintext)
-#   8883 — MQTTS (TLS, для prod надо настроить certSecret)
-#   8083 — MQTT over WebSocket
-#   18083 — EMQX Dashboard (admin/public по умолчанию — менять в prod!)
-#
-# Применение: kubectl apply -f deployments/k8s/emqx.yaml
-
----
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: emqx-config
-  namespace: sless
-data:
-  # emqx.conf — HOCON конфиг для EMQX 5.5.x
-  # Раздел authentication: HTTP Backend для проверки MQTT credentials IoT-устройств.
-  # Наш сервис (sless-operator) ищет Secret iot-{deviceId} и сравнивает пароль.
-  emqx.conf: |
-    ## EMQX 5.x configuration (HOCON format)
-    ## Изменено: 2026-04-04
-
-    ## HTTP Auth Backend для IoT-устройств
-    ## EMQX посылает POST с {username, password, clientid} → наш сервис отвечает {"result":"allow"|"deny"}
-    authentication = [
-      {
-        mechanism = password_based
-        backend = http
-        enable = true
-        method = post
-        url = "http://sless-operator.sless.svc:9090/internal/mqtt/auth"
-        body {
-          username = "${username}"
-          password = "${password}"
-          clientid = "${clientid}"
-        }
-        headers {
-          "content-type" = "application/json"
-        }
-        connect_timeout = 5s
-        request_timeout = 5s
-        ## allow_timeout_error = false — если наш сервис не отвечает, deny (безопаснее)
-        pool_size = 8
-      }
-    ]
-
-    ## ACL по умолчанию — разрешаем всё аутентифицированным клиентам
-    ## Тонкая ACL настраивается через HTTP auth response (поле acl)
-    authorization {
-      no_match = allow
-      deny_action = disconnect
-      cache {
-        enable = true
-        max_size = 32
-        ttl = 1m
-      }
-    }
-
-    ## MQTT настройки
-    mqtt {
-      max_packet_size = 1MB
-      max_topic_levels = 10
-      retain_available = false
-    }
-
-    ## Listeners — только plaintext MQTT для MVP
-    ## TLS (8883) отключён — настроить при необходимости
-    listeners.tcp.default {
-      bind = "0.0.0.0:1883"
-      max_connections = 1024
-    }
-
-    listeners.ws.default {
-      bind = "0.0.0.0:8083"
-      max_connections = 512
-    }
-
-    ## Dashboard
-    dashboard {
-      listeners.http {
-        bind = 18083
-      }
-    }
----
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: emqx
-  namespace: sless
-  labels:
-    app: emqx
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: emqx
-  template:
-    metadata:
-      labels:
-        app: emqx
-    spec:
-      containers:
-        - name: emqx
-          image: emqx/emqx:5.5.1
-          ports:
-            - name: mqtt
-              containerPort: 1883
-            - name: ws
-              containerPort: 8083
-            - name: dashboard
-              containerPort: 18083
-          volumeMounts:
-            - name: emqx-conf
-              mountPath: /opt/emqx/etc/emqx.conf
-              subPath: emqx.conf
-          resources:
-            requests:
-              memory: "256Mi"
-              cpu: "100m"
-            limits:
-              memory: "512Mi"
-              cpu: "500m"
-          readinessProbe:
-            tcpSocket:
-              port: 1883
-            initialDelaySeconds: 20
-            periodSeconds: 10
-            timeoutSeconds: 5
-          livenessProbe:
-            tcpSocket:
-              port: 1883
-            initialDelaySeconds: 40
-            periodSeconds: 20
-      volumes:
-        - name: emqx-conf
-          configMap:
-            name: emqx-config
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: emqx
-  namespace: sless
-spec:
-  selector:
-    app: emqx
-  ports:
-    - name: mqtt
-      port: 1883
-      targetPort: 1883
-    - name: ws
-      port: 8083
-      targetPort: 8083
-    - name: dashboard
-      port: 18083
-      targetPort: 18083

deployments/k8s/iot-mqtt-bridge.yaml

@@ -1,69 +0,0 @@
-# Создано: 2026-04-04
-# Deployment iot-mqtt-bridge — MQTT→RabbitMQ мост для IoT.
-#
-# Получает MQTT сообщения от EMQX (подписка на "+/telemetry/+")
-# и публикует в RabbitMQ queue "iot.{namespace}.telemetry".
-#
-# Credentials для MQTT подключения берутся из Secret iot-bridge-credentials.
-# Этот Secret нужно создать вручную ДО деплоя:
-#
-#   # 1. Создать IoTDevice для bridge через API:
-#   curl -X POST .../v1/namespaces/sless-bridge/iot/devices \
-#     -d '{"name":"bridge","device_id":"bridge","enabled":true}'
-#
-#   # 2. Получить credentials:
-#   MQTT_USERNAME=$(kubectl get secret iot-bridge -n sless-bridge -o jsonpath='{.data.mqtt-username}' | base64 -d)
-#   MQTT_PASSWORD=$(kubectl get secret iot-bridge -n sless-bridge -o jsonpath='{.data.mqtt-password}' | base64 -d)
-#
-#   # 3. Создать Secret для bridge Deployment (один раз):
-#   kubectl create secret generic iot-bridge-credentials -n sless \
-#     --from-literal=MQTT_USERNAME="$MQTT_USERNAME" \
-#     --from-literal=MQTT_PASSWORD="$MQTT_PASSWORD"
-#
-# Применение: kubectl apply -f deployments/k8s/iot-mqtt-bridge.yaml
-
----
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: iot-mqtt-bridge
-  namespace: sless
-  labels:
-    app: iot-mqtt-bridge
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: iot-mqtt-bridge
-  template:
-    metadata:
-      labels:
-        app: iot-mqtt-bridge
-    spec:
-      containers:
-        - name: mqtt-bridge
-          image: pearlharbor.registryk8s.services.ngcloud.ru/naeel/sless-operator:latest
-          # TODO: отдельный образ iot-mqtt-bridge После сборки через Makefile
-          imagePullPolicy: Always
-          command: ["/iot-mqtt-bridge"]
-          env:
-            - name: MQTT_BROKER_URL
-              value: "tcp://emqx.sless.svc:1883"
-            - name: RABBITMQ_URL
-              valueFrom:
-                secretKeyRef:
-                  name: sless-operator-secret
-                  key: RABBITMQ_URL
-                  optional: true
-          envFrom:
-            - secretRef:
-                name: iot-bridge-credentials
-          resources:
-            requests:
-              memory: "32Mi"
-              cpu: "25m"
-            limits:
-              memory: "64Mi"
-              cpu: "100m"
-      imagePullSecrets:
-        - name: sless-registry-auth

doc/ERR-PG-08-concurrent-operations.md

@@ -1,219 +0,0 @@
-# ERR-PG-08: Concurrent Operations Not Supported
-
-## Problem Statement
-
-After completing an Update operation on `nubes_postgres` resource (e.g., vault_secrets refresh), attempting to create any dependent resource immediately fails with API 422 error:
-
-```
-Error: Ошибка клиента
-  ошибка API 422: {
-    "DETAIL": "There is a started operation on this instance",
-    "TYPE": "about:blank",
-    "TITLE": "Concurrent operations are not supported (job status: SUCCESS)"
-  }
-```
-
-Even though `WaitForOperation()` has returned successfully and the previous operation is marked as completed.
-
-## Reproduction
-
-1. Terraform plan detects vault_secrets has changed (external drift)
-2. Execute update: `nubes_postgres.pg_test_instance: Modifying...`
-3. Update completes: `nubes_postgres.pg_test_instance: Modifications complete after 0s`
-4. Immediately try to create: `nubes_postgres_database.pg_test_db: Creating...`
-5. **FAIL**: API returns 422 "Concurrent operations are not supported"
-
-## Why It Happens
-
-The Nubes API has an internal operation lock per instance. Even though the Update operation's `IsSuccessful` flag is true and operations are no longer in-progress, the API server is still processing asynchronous side effects:
-- Vault credential updates
-- Instance state synchronization
-- Backend resource reconciliation
-
-When the next Create operation is submitted, the lock is still held, causing the 422 error.
-
-## Current Symptoms
-
-- Affects: Any sequence where Update → Create operations happen on same instance
-- Timing: Happens even with 120+ second waits
-- Scope: Affects DB creation, user creation, any operation on PostgreSQL instance
-- Test environment: Confirmed on `k8s-3-sandbox-nubes-ru` realm
-- Production: Unknown (not tested)
-
-## Workarounds (Current)
-
-### Workaround 1: Split Resources Across Apply Cycles
-Comment out dependent resource creation, apply first update, then uncomment and apply again:
-
-```hcl
-# postgres.tf
-# temporarily comment out nubes_postgres_database block
-# terraform apply  ← creates pg_test_instance + users
-# uncomment nubes_postgres_database block
-# terraform apply  ← creates pg_test_db
-```
-
-Already implemented in this project (see [postgres.tf lines 87-99](../examples/PG_TEST/postgres.tf#L87-L99)).
-
-### Workaround 2: Add Explicit depends_on + relies on Terraform serialization
-```hcl
-resource "nubes_postgres_database" "pg_test_db" {
-  postgres_id = nubes_postgres.pg_test_instance.id
-  db_name     = var.pg_db_name
-  db_owner    = nubes_postgres_user.pg_test_user.username
-  
-  # Explicit depends_on forces sequential execution
-  # but does NOT help with concurrent operation lock
-  depends_on = [nubes_postgres_user.pg_test_user3]
-}
-```
-
-**Status**: Doesn't solve the problem - API still returns 422.
-
-### Workaround 3: Manual Sequential Runs
-```bash
-# First apply - creates instance and users
-terraform apply -auto-approve
-
-# Wait manually (or check instance state)
-sleep 180
-
-# Second apply - creates databases
-terraform apply -auto-approve
-```
-
-This is **unreliable** and not automatable.
-
-## Root Cause Analysis
-
-### Client-Side (Terraform Provider)
-
-**File**: [`internal/provider/client_impl.go`](../../terra/terraform/internal/provider/client_impl.go) line 240
-
-```go
-func (c *NubesClient) WaitForOperation(ctx context.Context, opUid string) error {
-    timeout := time.After(15 * time.Minute)
-    ticker := time.NewTicker(10 * time.Second)
-    // ...
-    
-    // Checks every 10 seconds for operation completion
-    if !op.IsInProgress && !op.IsPending && op.DtFinish != nil {
-        if op.IsSuccessful != nil && *op.IsSuccessful {
-            return nil  // ← Returns immediately when successful
-        }
-    }
-}
-```
-
-**Problem**: No post-completion delay or retry logic for subsequent operations.
-
-### Server-Side (Nubes API)
-
-The API maintains an operation lock on the instance that:
-1. Is released when operation completes (`IsSuccessful = true`)
-2. **But** async background tasks are still running during the lock release window
-3. New requests during this window: "There is a started operation on this instance"
-
-This is an **intentional safety measure** against corrupting instance state, but the window between "operation done" and "instance ready for next operation" is not deterministic.
-
-## Solutions (For Provider Fix)
-
-### Option 1: Add Post-Completion Delay
-**Pros**: Simple, guaranteed to work
-**Cons**: Always adds overhead, even if not needed
-
-```go
-// In client_impl.go, after "return nil" on success:
-if op.IsSuccessful != nil && *op.IsSuccessful {
-    // Add buffer for API server to release internal locks
-    time.Sleep(30 * time.Second)  // or configurable
-    return nil
-}
-```
-
-**Recommended value**: `30-60 seconds` based on observations.
-
-### Option 2: Implement Retry Mechanism
-**Pros**: No unnecessary delays, adapts to actual API response time
-**Cons**: More complex, needs careful timeout/backoff tuning
-
-When next operation fails with "concurrent operations", retry with exponential backoff:
-```go
-func (c *NubesClient) CreateResourceWithRetry(ctx context.Context, payload map[string]interface{}) error {
-    maxRetries := 5
-    backoff := 10 * time.Second
-    
-    for i := 0; i < maxRetries; i++ {
-        err := c.Create(ctx, payload)
-        if err == nil {
-            return nil
-        }
-        if strings.Contains(err.Error(), "Concurrent operations") {
-            time.Sleep(backoff)
-            backoff *= 2  // exponential backoff
-            continue
-        }
-        return err
-    }
-}
-```
-
-**Backoff suggestion**: Start 10s, cap at 60s.
-
-### Option 3: Query Instance State Before Next Operation
-**Pros**: Most elegant, confirms instance is ready
-**Cons**: Requires additional API call, might still be unreliable
-
-```go
-func (c *NubesClient) WaitForInstanceReady(ctx context.Context, instanceId string) error {
-    // Poll instance state directly, not just operation state
-    for retry := 0; retry < 30; retry++ {
-        state, err := c.GetInstanceState(ctx, instanceId)
-        if err == nil && state.IsReady {
-            return nil
-        }
-        time.Sleep(5 * time.Second)
-    }
-    return fmt.Errorf("instance not ready after timeout")
-}
-```
-
-## Recommendation
-
-**Implement Option 1 (Post-Completion Delay)** combined with **Option 2 (Retry Logic)**:
-
-1. Add fixed 30-second delay after `WaitForOperation` returns success (**fail-safe**)
-2. Keep retry mechanism for cases where clients don't respect the delay (**defensive**)
-
-This provides both reliability (fixed delay) and robustness (retry on failure).
-
-## Testing
-
-**Test case**:
-```bash
-cd examples/PG_TEST
-
-# Uncomment pg_test_db in postgres.tf
-terraform apply -auto-approve
-
-# Should NOT fail with 422 "Concurrent operations are not supported"
-# Should create all 3 resources: instance, users, database
-```
-
-**Current status**: ❌ FAILS with 422
-
-**After fix**: ✅ SHOULD PASS
-
-## References
-
-- Provider source: `/home/naeel/terra/terraform/internal/provider/`
-- Test configuration: `/home/naeel/terra/sless/examples/PG_TEST/`
-- Related: ERR-PG-02 (fixed), ERR-PG-03 (race condition), ERR-PG-04 (invalid role)
-- Vault credentials: Not involved in this error (different subsystem)
-
----
-
-**Date discovered**: 2026-04-03  
-**Status**: Open, blocker for multi-resource deployments  
-**Priority**: High (blocks full lifecycle automation)  
-**Scope**: Test environment confirmed, production unknown

doc/SESSION_REPORT_2026-04-03.md

@@ -1,170 +0,0 @@
-# Session Report: PostgreSQL Discovery - April 3, 2026
-
-## Session Overview
-
-**Duration**: Single session, April 3, 2026  
-**Focus**: Root cause analysis of PostgreSQL terraform lifecycle tests failures  
-**Outcome**: 2 major problems identified and documented
-
----
-
-## Key Findings
-
-### 1. ERR-PG-02: FIXED ✅
-
-**Previously**: ID going to `(known after apply)` during Update operations
-
-**Status**: Already fixed in current provider code (`internal/provider/postgres_resource.go` line ~845)
-- Code now explicitly preserves ID from state during Update
-- No longer reproducible - no destroy+recreate of dependent resources
-
-**Verification**: `terraform plan` shows `0 to destroy` (correct behavior)
-
----
-
-### 2. ERR-PG-06: RECLASSIFIED 🔄
-
-**Previously**: Claimed that only 1 user per PostgreSQL instance could be created with vault_secrets
-
-**Corrected Finding**: Multiple users work fine when properly configured
-- Successfully created `pg_test_user` (user0) and `pg_test_user3` (u3)
-- Both have vault_secrets successfully populated
-
-**Root Cause of Original Error**: Lack of `depends_on` between user resources → race condition in Vault writes
-
-**Solution**: Strict `depends_on` chain between users is required and works perfectly
-
----
-
-### 3. ERR-PG-08: NEW PROBLEM ❌
-
-**Description**: After Update operation completes (even successfully), creating dependent resources fails with 422 "Concurrent operations are not supported"
-
-**Symptoms**:
-```
-Error: Ошибка клиента
-  ошибка API 422: {
-    "TITLE": "Concurrent operations are not supported (job status: SUCCESS)"
-  }
-```
-
-**Root Cause**: Nubes API maintains internal lock on instance even after operation completion. Post-operation async tasks (Vault sync, state reconciliation) still run.
-
-**Impact**: Cannot create databases or additional users immediately after instance update in same Terraform apply
-
-**Workaround Found**: Split apply into phases (comment out DB resource, apply, uncomment, apply again)
-
-**Requires**: Provider fix - add post-completion delay or retry mechanism in `WaitForOperation()` method
-
----
-
-## Documentation Created
-
-1. **[/home/naeel/remote_dev/sless/doc/ERR-PG-08-concurrent-operations.md](./ERR-PG-08-concurrent-operations.md)**
-   - Detailed problem analysis
-   - 3 solution options (fixed delay, retry mechanism, instance state query)
-   - Recommendation: combine options 1 + 2
-
-2. **Updated [/home/naeel/remote_dev/sless/doc/errors/log.md](./errors/log.md)**
-   - Added corrections to ERR-PG-06 (multi-user now works)
-   - Added new section for ERR-PG-08 (concurrent ops limitation)
-
-3. **Updated [/home/naeel/remote_dev/sless/doc/pg-terraform-behavior.md](./pg-terraform-behavior.md)**
-   - Table (section 6) updated: shows 2nd/3rd user creation now works
-   - Added section 3.5: detailed ERR-PG-08 explanation
-   - Corrected: "2 users per instance" now says "Works with depends_on"
-
----
-
-## Terraform Configuration Status
-
-**Current Setup** (`examples/PG_TEST`):
-- ✅ `nubes_postgres` instance created successfully
-- ✅ `pg_test_user` (user0) created successfully  
-- ✅ `pg_test_user3` (u3) created successfully
-- ❌ `pg_test_db` cannot be created (blocked by ERR-PG-08)
-
-**Workaround Applied**:
-- [x] Commented out `nubes_postgres_database` resource block (lines 87-99)
-- [x] Updated outputs.tf to disable database-dependent outputs
-- [x] Successfully applied (0 added, 1 changed, 0 destroyed)
-
-**Status**: Awaiting provider fix to re-enable database creation
-
----
-
-## Provider Source Files
-
-**Identified locations** for fix:
-- `/home/naeel/terra/terraform/internal/provider/client_impl.go` line 240
-  - `WaitForOperation()` method needs post-completion handling
-  - Current: returns immediately on `IsSuccessful = true`
-  - Needed: add delay or retry mechanism
-
-- `/home/naeel/terra/terraform/internal/provider/postgres_resource.go` line 617+
-  - Update() method (already has ERR-PG-02 fix)
-  - Would benefit from handling ERR-PG-08 retries
-
----
-
-## Next Steps (For Future Sessions)
-
-1. **Priority FIX**: Implement post-completion delay in `WaitForOperation()`
-   - Add 30-60 second sleep after success return
-   - Or implement exponential backoff retry for 422 errors
-
-2. **Testing**: After fix applied
-   - Re-enable `nubes_postgres_database` in postgres.tf
-   - Verify `terraform apply` succeeds fully (0 destroyed)
-   - Run stress tests with multiple users and databases
-
-3. **Documentation**: After fix verified
-   - Update `pg-terraform-behavior.md` table (remove ERR-PG-08 workaround)
-   - Mark ERR-PG-08 as "FIXED"
-   - Update provider-fix-plan.md with implementation details
-
-4. **Codebase**: Commit changes
-   - Provider fix in `/home/naeel/terra/terraform/`
-   - Documentation updates in `/home/naeel/remote_dev/sless/`
-
----
-
-## Files Modified This Session
-
-### In `/home/naeel/remote_dev/sless/`
-
-- ✅ [doc/ERR-PG-08-concurrent-operations.md](./doc/ERR-PG-08-concurrent-operations.md) — CREATED (new)
-- ✅ [doc/errors/log.md](./doc/errors/log.md) — UPDATED (added corrections + ERR-PG-08)
-- ✅ [doc/pg-terraform-behavior.md](./doc/pg-terraform-behavior.md) — UPDATED (table + section 3.5)
-- ⚠️ [examples/PG_TEST/postgres.tf](./examples/PG_TEST/postgres.tf) — MODIFIED (commented out DB)
-- ⚠️ [examples/PG_TEST/outputs.tf](./examples/PG_TEST/outputs.tf) — MODIFIED (disabled DB outputs)
-
-### On VM `/home/naeel/terra/`
-
-- No code changes (only investigation)
-- Terraform state reflects multi-user success
-- Provider source examined but not modified
-
----
-
-## Lessons Learned
-
-1. **Multi-user creation works** when using proper `depends_on` chains
-2. **Vault limitation hypothesis was wrong** - it was a race condition issue
-3. **Concurrent operations limit is real** and requires provider-level fix
-4. **Provider already has one fix** (ERR-PG-02 id preservation) - shows active maintenance
-5. **Test environment is functional** despite appearing to fail initially
-
----
-
-## Technical Debt
-
-- [ ] ERR-PG-08 requires provider fix (not blocking test framework, blocking full automation)
-- [ ] Consider: Is concurrent operations lock intentional safety feature? Document if so.
-- [ ] Consider: Add configurable retry delays for production resilience
-
----
-
-**Session Status**: COMPLETE - Major findings documented, actionable recommendations provided
-
-**Ready For**: Next programmer to implement provider fix based on documented analysis

doc/decisions/vm-install-functions-plan.md

@@ -1,500 +0,0 @@
-# План-инструкция: sless_job функции для установки ПО в ВМ
-
-> 2026-03-29 — Инструкция для AI-агента (GPT/Claude/Codex).
-> Цель: демонстрация заказчику связки Terraform + Serverless.
-> Один `terraform apply` — поднимается vApp/VM + автоматически устанавливается ПО.
-
----
-
-## Контекст: что уже есть
-
-```
-examples/VM/
-├── main.tf          # provайдер nubes, переменные (api_token, vm_public_key)
-├── vapp.tf          # nubes_vapp.vapp — контейнер ВМ
-├── vm.tf            # nubes_vc_vm_v3.vm — Ubuntu 22.04, 2CPU/2GB/20GB
-├── terraform.tfvars # токены (gitignored)
-├── vm_key / vm_key.pub  # SSH-ключ для ВМ
-└── .terraform/      # init уже выполнен
-```
-
-**ВМ поднята и работает.** IP: `nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]`.
-SSH: `ssh -i vm_key ubuntu@<IP>`.
-
-Платформа sless поднята: оператор v0.1.62, API `https://sless.kube5s.ru`.
-
----
-
-## Что нужно сделать
-
-Добавить в `examples/VM/` sless-провайдер и набор `sless_job` ресурсов, которые по SSH
-устанавливают ПО на ВМ. Пользователь шаблона включает нужные флагами.
-
-### Целевой результат для заказчика
-
-```bash
-cd examples/VM
-# пользователь выставляет флаги:
-#   install_docker   = true
-#   install_postgres = true
-terraform apply
-# → vApp + VM создаются (или уже есть)
-# → джобы подключаются по SSH и ставят Docker, PostgreSQL и т.д.
-# → outputs показывают статус каждого шага
-```
-
----
-
-## Архитектура: СТРОГО sless_job
-
-- Каждая установка = отдельный `sless_job` (one-shot, execution task).
-- НЕ создавать `sless_service` (у функций-установщиков нет постоянного URL).
-- НЕ создавать новый Terraform resource — только `sless_job`.
-- Передача параметров: `env_vars` — для подключения (IP, ключ), `event_json` — для бизнес-логики.
-
----
-
-## Файловая структура (целевая)
-
-```
-examples/VM/
-├── main.tf                 # + добавить provider "sless"
-├── vapp.tf                 # без изменений
-├── vm.tf                   # без изменений
-├── variables.tf            # NEW — все переменные (включая флаги install_*)
-├── sless.tf                # NEW — provider sless + sless_job ресурсы
-├── outputs.tf              # NEW — outputs статусов джобов
-├── terraform.tfvars        # + добавить sless_token, флаги
-│
-├── functions/              # NEW — код функций-установщиков
-│   ├── install-packages/
-│   │   ├── handler.py
-│   │   └── requirements.txt  # paramiko
-│   ├── install-docker/
-│   │   ├── handler.py
-│   │   └── requirements.txt
-│   └── install-postgres/
-│       ├── handler.py
-│       └── requirements.txt
-│
-├── vm_key / vm_key.pub
-└── .terraform/
-```
-
----
-
-## Контракт Python handler для sless_job
-
-```python
-# handler.py — загружается в контейнер как /app/function/handler.py
-# Рантайм: python3.11
-# Вызывается один раз, результат = JSON → записывается в job.message
-
-import os
-
-def install(event):
-    """
-    event — dict из event_json Terraform-ресурса.
-    os.environ — содержит env_vars из Terraform-ресурса.
-    
-    Возврат:
-      dict/list → JSON (phase=Succeeded, message=json)
-      raise Exception → phase=Failed, message=traceback
-    """
-    vm_ip    = os.environ["VM_IP"]
-    ssh_user = os.environ["SSH_USER"]
-    ssh_key  = os.environ["SSH_KEY"]    # содержимое приватного ключа (PEM)
-    
-    packages = event.get("packages", [])
-    
-    # ... SSH + установка ...
-    
-    return {"status": "ok", "installed": packages}
-```
-
----
-
-## Спецификация каждой функции
-
-### 1. install-packages (Этап A — первый)
-
-**Назначение:** Универсальный apt-установщик. Ставит произвольный список пакетов.
-
-**handler.py** — entrypoint: `handler.install`
-
-```
-event_json:
-  packages: ["git", "curl", "htop", "..."]     # обязательно — список имён пакетов apt
-  update: true                                   # опционально — apt update перед install (default: true)
-
-env_vars:
-  VM_IP:    nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
-  SSH_USER: "ubuntu"
-  SSH_KEY:  file("${path.module}/vm_key")
-
-requirements.txt:
-  paramiko
-```
-
-**Логика:**
-1. Подключиться по SSH через paramiko (ключ из env var, не из файла на диске).
-2. `sudo apt-get update` (если event.update != false).
-3. `sudo DEBIAN_FRONTEND=noninteractive apt-get install -y <packages>`.
-4. Проверить `dpkg -l <package>` для каждого.
-5. Вернуть `{"status": "ok", "installed": [...], "already_installed": [...], "failed": [...]}`.
-
-**Обработка ошибок:**
-- SSH connection refused → retry 3 раза с шагом 10 сек (ВМ может ещё грузиться).
-- apt lock → retry 5 раз с шагом 15 сек.
-- Частичный фейл (2 из 5 пакетов не найдены) → status="partial", failed=[...].
-- Полный фейл → raise Exception с читаемым сообщением.
-
-**Идемпотентность:** Повторный запуск безопасен — apt-get install -y ничего не ломает.
-
-### 2. install-docker (Этап A)
-
-**Назначение:** Docker CE + docker-compose plugin по официальной инструкции.
-
-**handler.py** — entrypoint: `handler.install`
-
-```
-event_json:
-  compose: true          # опционально — ставить ли docker-compose plugin (default: true)
-
-env_vars:
-  VM_IP, SSH_USER, SSH_KEY  — те же
-
-requirements.txt:
-  paramiko
-```
-
-**Логика:**
-1. SSH → проверить `docker --version`. Если уже есть — вернуть `{"status": "already_installed", ...}`.
-2. Добавить Docker apt-репозиторий (GPG ключ + sources.list).
-3. `apt-get install docker-ce docker-ce-cli containerd.io`.
-4. Если compose=true → `apt-get install docker-compose-plugin`.
-5. `sudo usermod -aG docker $SSH_USER`.
-6. Проверить: `docker run hello-world`.
-7. Вернуть `{"status": "ok", "docker_version": "...", "compose": true/false}`.
-
-**Идемпотентность:** Проверяет наличие перед установкой.
-
-### 3. install-postgres (Этап B)
-
-**Назначение:** PostgreSQL сервер + создание БД и пользователя.
-
-**handler.py** — entrypoint: `handler.install`
-
-```
-event_json:
-  pg_version: "14"                # опционально (default: "14")
-  db_name: "myapp"                # обязательно — имя БД
-  db_user: "app_user"             # обязательно — имя пользователя
-  db_password: "secure_pass"      # обязательно — пароль
-  listen_addresses: "*"           # опционально (default: "localhost")
-  allow_remote: true              # опционально — добавлять ли в pg_hba.conf (default: false)
-
-env_vars:
-  VM_IP, SSH_USER, SSH_KEY  — те же
-
-requirements.txt:
-  paramiko
-```
-
-**Логика:**
-1. SSH → проверить `psql --version`. Если нет:
-   - `apt-get install postgresql postgresql-contrib postgresql-client`.
-2. `systemctl is-active postgresql` — убедиться что запущен.
-3. Создать пользователя: `sudo -u postgres psql -c "CREATE USER ... PASSWORD ..."` (IF NOT EXISTS).
-4. Создать БД: `sudo -u postgres psql -c "CREATE DATABASE ... OWNER ..."` (IF NOT EXISTS).
-5. Если allow_remote: настроить `listen_addresses` в postgresql.conf + запись в pg_hba.conf.
-6. `systemctl restart postgresql` (если конфиг менялся).
-7. Проверить подключение: `psql -h localhost -U <user> -d <db> -c "SELECT 1"`.
-8. Вернуть `{"status": "ok", "pg_version": "14.x", "db_name": "myapp", ...}`.
-
-**Идемпотентность:** IF NOT EXISTS для пользователя и БД. Config-записи — grep перед append.
-
----
-
-## Terraform: sless.tf (скелет)
-
-```hcl
-# 2026-03-29 — sless.tf: sless_job функции для установки ПО на ВМ.
-# Каждый job подключается по SSH и ставит ПО.
-
-provider "sless" {
-  endpoint = "https://sless.kube5s.ru"
-  token    = var.sless_token
-}
-
-# --- Общие локальные переменные ---
-locals {
-  vm_ip    = nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
-  ssh_user = "ubuntu"
-  ssh_key  = file("${path.module}/vm_key")
-
-  # Общий набор env_vars для SSH-подключения к ВМ
-  ssh_env = {
-    VM_IP    = local.vm_ip
-    SSH_USER = local.ssh_user
-    SSH_KEY  = local.ssh_key
-  }
-}
-
-# --- 1. Базовые пакеты ---
-resource "sless_job" "install_packages" {
-  count = var.install_packages ? 1 : 0
-
-  name       = "vm-install-packages"
-  runtime    = "python3.11"
-  entrypoint = "handler.install"
-  source_dir = "${path.module}/functions/install-packages"
-
-  env_vars   = local.ssh_env
-  event_json = jsonencode({
-    packages = var.base_packages
-  })
-
-  run_id           = var.install_run_id
-  wait_timeout_sec = 600
-
-  depends_on = [nubes_vc_vm_v3.vm]
-}
-
-# --- 2. Docker ---
-resource "sless_job" "install_docker" {
-  count = var.install_docker ? 1 : 0
-
-  name       = "vm-install-docker"
-  runtime    = "python3.11"
-  entrypoint = "handler.install"
-  source_dir = "${path.module}/functions/install-docker"
-
-  env_vars   = local.ssh_env
-  event_json = jsonencode({
-    compose = true
-  })
-
-  run_id           = var.install_run_id
-  wait_timeout_sec = 900
-
-  depends_on = [
-    nubes_vc_vm_v3.vm,
-    sless_job.install_packages   # пакеты первыми
-  ]
-}
-
-# --- 3. PostgreSQL ---
-resource "sless_job" "install_postgres" {
-  count = var.install_postgres ? 1 : 0
-
-  name       = "vm-install-postgres"
-  runtime    = "python3.11"
-  entrypoint = "handler.install"
-  source_dir = "${path.module}/functions/install-postgres"
-
-  env_vars   = local.ssh_env
-  event_json = jsonencode({
-    pg_version    = var.pg_version
-    db_name       = var.pg_db_name
-    db_user       = var.pg_db_user
-    db_password   = var.pg_db_password
-    allow_remote  = var.pg_allow_remote
-  })
-
-  run_id           = var.install_run_id
-  wait_timeout_sec = 900
-
-  depends_on = [
-    nubes_vc_vm_v3.vm,
-    sless_job.install_packages   # базовые пакеты первыми
-  ]
-}
-```
-
-## Terraform: variables.tf (скелет)
-
-```hcl
-# 2026-03-29 — variables.tf: все переменные для examples/VM.
-
-# --- Nubes (уже есть, перенести из main.tf) ---
-variable "api_token"      { type = string; sensitive = true }
-variable "vm_public_key"  { type = string; sensitive = true }
-
-# --- Sless ---
-variable "sless_token" {
-  type        = string
-  sensitive   = true
-  description = "JWT-токен для sless API"
-}
-
-# --- Флаги установки ---
-variable "install_packages" {
-  type    = bool
-  default = true
-  description = "Установить базовые apt-пакеты"
-}
-
-variable "install_docker" {
-  type    = bool
-  default = false
-  description = "Установить Docker CE"
-}
-
-variable "install_postgres" {
-  type    = bool
-  default = false
-  description = "Установить PostgreSQL"
-}
-
-# --- Параметры ---
-variable "base_packages" {
-  type    = list(string)
-  default = ["git", "curl", "htop", "jq", "unzip"]
-  description = "Список apt-пакетов для install-packages"
-}
-
-variable "install_run_id" {
-  type    = number
-  default = 1
-  description = "Увеличить для повторного запуска всех install-джобов"
-}
-
-# --- PostgreSQL ---
-variable "pg_version"      { type = string;  default = "14" }
-variable "pg_db_name"      { type = string;  default = "myapp" }
-variable "pg_db_user"      { type = string;  default = "app_user" }
-variable "pg_db_password"  { type = string;  sensitive = true; default = "" }
-variable "pg_allow_remote" { type = bool;    default = false }
-```
-
-## Terraform: outputs.tf (скелет)
-
-```hcl
-# 2026-03-29 — outputs.tf: статусы установки.
-
-output "install_packages_result" {
-  value = var.install_packages ? sless_job.install_packages[0].message : "skipped"
-}
-
-output "install_docker_result" {
-  value = var.install_docker ? sless_job.install_docker[0].message : "skipped"
-}
-
-output "install_postgres_result" {
-  value = var.install_postgres ? sless_job.install_postgres[0].message : "skipped"
-}
-```
-
----
-
-## Порядок выполнения для агента
-
-### Фаза 1: Инфраструктура Terraform (4 файла)
-
-1. Создать `variables.tf` — все переменные (перенести из main.tf + новые).
-2. Создать `sless.tf` — провайдер sless + 3 ресурса sless_job.
-3. Создать `outputs.tf` — статусы.
-4. Обновить `main.tf` — вынести переменные в variables.tf, добавить required_providers sless.
-
-> **Проверка:** `terraform validate` должен пройти.
-
-### Фаза 2: Функция install-packages (1 функция, полный E2E)
-
-1. Создать `functions/install-packages/handler.py`.
-2. Создать `functions/install-packages/requirements.txt` (paramiko).
-3. Добавить `sless_token` в `terraform.tfvars`.
-4. `terraform apply` с `install_packages = true`.
-5. Убедиться: `phase = Succeeded`, пакеты установлены на ВМ.
-
-> **Это ключевой момент.** Если install-packages прошёл E2E — паттерн работает, остальные функции аналогичны.
-
-### Фаза 3: Функции install-docker и install-postgres
-
-1. Создать `functions/install-docker/handler.py` + `requirements.txt`.
-2. Создать `functions/install-postgres/handler.py` + `requirements.txt`.
-3. `terraform apply` с `install_docker = true, install_postgres = true`.
-4. Проверить: Docker установлен, PostgreSQL работает, БД создана.
-
-### Фаза 4: Полировка и README
-
-1. Обновить `README.md` — как использовать шаблон с sless.
-2. `terraform apply` с нуля (destroy + apply) — весь цикл.
-
----
-
-## SSH через paramiko — референсный паттерн
-
-```python
-# Этот блок — основа для всех handler.py. Копировать и адаптировать.
-
-import os, io, time
-import paramiko
-
-def _ssh_connect(retries=3, delay=10):
-    """Подключение к ВМ по SSH. Retry при connection refused (ВМ грузится)."""
-    key = paramiko.Ed25519Key.from_private_key(io.StringIO(os.environ["SSH_KEY"]))
-    for attempt in range(retries):
-        try:
-            client = paramiko.SSHClient()
-            client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
-            client.connect(
-                hostname=os.environ["VM_IP"],
-                username=os.environ["SSH_USER"],
-                pkey=key,
-                timeout=15,
-            )
-            return client
-        except Exception as e:
-            if attempt == retries - 1:
-                raise RuntimeError(f"SSH connection failed after {retries} attempts: {e}")
-            time.sleep(delay)
-
-def _ssh_run(client, cmd, check=True):
-    """Выполнить команду. При check=True — бросить ошибку если exit_code != 0."""
-    stdin, stdout, stderr = client.exec_command(cmd, timeout=300)
-    exit_code = stdout.channel.recv_exit_status()
-    out = stdout.read().decode().strip()
-    err = stderr.read().decode().strip()
-    if check and exit_code != 0:
-        raise RuntimeError(f"Command failed (exit {exit_code}): {cmd}\nstderr: {err}")
-    return exit_code, out, err
-```
-
----
-
-## Ограничения и подводные камни
-
-1. **SSH через внешний IP** — Sless-поды находятся в k8s кластере `kube5s.ru`, VM — в Nubes vDC.
-   Эти сети **не связаны напрямую**. Используем `externalConnect` (публичный IP).
-   `internalConnect` (`10.x.x.x`) доступен только внутри Nubes vDC — из sless-подов он недостижим.
-
-   > **TODO для DevOps облака Nubes:** обсудить организацию внутреннего трафика между
-   > k8s кластером и Nubes vDC — VPN/peering/dedicated link. До решения — только внешний IP.
-   > Когда появится внутренний маршрут — заменить `externalConnect` → `internalConnect` в locals.
-
-   В `sless.tf`:
-   ```hcl
-   # TODO: заменить на internalConnect когда DevOps настроят сеть между кластером и vDC
-   vm_ip = nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
-   ```
-
-2. **SSH_KEY в env_var** — Содержимое приватного ключа передаётся как env var (строка).
-   paramiko умеет читать из `io.StringIO`. Не писать в файл.
-
-2. **apt lock** — Если apt уже заблокирован (unattended-upgrades), будет ошибка.
-   Retry с проверкой `/var/lib/dpkg/lock-frontend`.
-
-3. **depends_on обязателен** — ВМ должна быть готова до запуска job.
-   `depends_on = [nubes_vc_vm_v3.vm]`. Без этого terraform может запустить параллельно.
-
-4. **run_id для повторного запуска** — sless_job не перезапускается автоматически.
-   Чтобы перезапустить: `install_run_id = 2` → `terraform apply`.
-
-5. **wait_timeout_sec** — Kaniko-сборка + выполнение. 600с для мелких пакетов, 900с для Docker/PG.
-
-6. **Vault пока нет** — Секреты (pg_password, ssh_key) передаются через tfvars.
-   Архитектура готова к замене на Vault data source позже (env_vars заполняются из vault).
-
-7. **Drift не отслеживается** — Job-модель ≠ полноценный stateful resource.
-   Если кто-то удалит Docker на ВМ — Terraform не знает. Перезапуск: увеличить run_id.

doc/errors/log.md

@@ -4,431 +4,6 @@
 
 ---
 
-## 2026-04-01 — Nubes PostgreSQL API: ошибки при создании ресурсов (PG_TEST)
-
-Все ошибки воспроизводились в `examples/PG_TEST` при тестировании провайдера
-`terra.k8c.ru/nubes/nubes` v5.0.51. VM: `naeel@5.172.178.213`, PG-инстанс: `pg-test-02`.
-
----
-
-### ERR-PG-01: "Invalid JSON String" при создании инстанса с json_parameters
-
-**Симптом**
-
-```
-Error: Ошибка клиента
-  with nubes_postgres.pg_test_instance
-  Invalid JSON String
-```
-
-**Причина**
-
-При передаче параметра `json_parameters` (строка JSON с кастомными настройками PG)
-Nubes API v5 возвращает "Invalid JSON String" независимо от корректности самого JSON.
-Вероятно — баг в провайдере или несовместимость формата с deck-api-test.
-
-**Решение**
-
-Убран `json_parameters` из конфигурации `nubes_postgres`. PG запускается
-с дефолтными параметрами движка. При необходимости custom params — требует
-диагностики на стороне Nubes (`.api_endpoint = deck-api-test.ngcloud.ru`).
-
-**Файл:** [examples/PG_TEST/postgres.tf](examples/PG_TEST/postgres.tf)
-
----
-
-### ERR-PG-02: vault_secrets меняется вне Terraform → destroy+recreate всей цепочки
-
-**Симптом**
-
-Каждый `terraform apply` обнаруживает изменения "снаружи Terraform":
-
-```
-Note: Objects have changed outside of Terraform
-  # nubes_postgres.pg_test_instance has changed
-  ~ vault_secrets = (sensitive value)
-```
-
-Это вызывает план с `-/+ destroy and then create replacement` для `pg_test_user`
-и `pg_test_db`, хотя реально они не изменились.
-
-**Причина**
-
-Nubes API обновляет `vault_secrets` (путь к Vault с паролями пользователей)
-каждый раз при создании/удалении пользователей. Terraform видит это как
-"изменение снаружи" и считает `postgres_id` изменённым (т.к. он `(known after apply)`
-после обновления инстанса), что форсирует замену всех дочерних ресурсов.
-
-**Попытка решения**
-
-Добавить `lifecycle { ignore_changes = [vault_secrets] }` — **не работает**.
-Terraform выводит предупреждение:
-> "The attribute vault_secrets is decided by the provider alone and therefore
-> there can be no configured value to compare with. Including this attribute
-> in ignore_changes has no effect."
-
-`vault_secrets` — Computed-only (провайдер его полностью контролирует),
-`ignore_changes` для таких атрибутов игнорируется.
-
-**Реальная причина** destroy+recreate: при обнаружении `vault_secrets` как
-"изменённого снаружи" Terraform обновляет `nubes_postgres` in-place, но
-в плане ставит `id = (known after apply)` — это форсирует замену зависимых
-ресурсов у которых `postgres_id` ссылается на `nubes_postgres.*.id`.
-
-**Статус: открытая проблема.** Обходной путь — выполнять `apply` только на
-чистом state (без накопленных изменений снаружи). После первого полного
-`apply` с `lifecycle ignore_changes` убран как неэффективный.
-
-**Файл:** [examples/PG_TEST/postgres.tf](examples/PG_TEST/postgres.tf)
-
----
-
-### ERR-PG-03: Race condition при параллельном создании пользователей
-
-**Симптом**
-
-При одновременном создании двух и более `nubes_postgres_user` на одном инстансе:
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_user.test_extra_user1
-  операция XXXX завершилась с ошибкой: Секрет для пользователя extra_user1 не был создан
-```
-
-Или:
-
-```
-  операция XXXX завершилась с ошибкой: key doesn't exist
-```
-
-**Причина**
-
-Nubes API не поддерживает параллельное создание пользователей на одном PG-инстансе.
-Внутри Nubes: каждое создание пользователя пишет в Vault, а Vault/Deck
-не справляются с конкурентными записями в один Secret.
-
-**Решение**
-
-Принудительная последовательная цепочка через `depends_on`:
-
-```
-pg_test_user → pg_test_db → extra_user1 → extra_user2 → extra_db1 → extra_db2
-```
-
-Каждый `nubes_postgres_user` и `nubes_postgres_database` явно ждёт предыдущий.
-`depends_on` нужен даже если прямой ссылки на атрибуты нет.
-
-**Файлы:** [examples/PG_TEST/postgres.tf](examples/PG_TEST/postgres.tf),
-[examples/PG_TEST/postgres_extra.tf](examples/PG_TEST/postgres_extra.tf)
-
----
-
-### ERR-PG-04: Роль app_user не работает для nubes_postgres_user
-
-**Симптом**
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_user.test_app_user,
-  операция XXXX завершилась с ошибкой: Секрет для пользователя test_app_user не был создан
-```
-
-Ресурс висит ~3 минуты перед ошибкой. Воспроизводится стабильно.
-
-**Причина**
-
-Роль `app_user` не поддерживается для создания PostgreSQL пользователей
-через `nubes_postgres_user` в данной версии провайдера/API. Возможно, роль
-предусмотрена только для другого механизма доступа.
-
-**Решение**
-
-Использовать только роль `ddl_user` для ресурса `nubes_postgres_user`.
-Создание пользователей с `app_user` — не работает на `deck-api-test.ngcloud.ru`.
-
-Из конфигурации удалён ресурс `nubes_postgres_user.test_app_user`.
-
----
-
-### ERR-PG-05: "Нарушена консистентность" — пользователь есть в API, нет в state_out
-
-**Симптом**
-
-```
-Error: Нарушена консистентность
-  with nubes_postgres_user.test_extra_user1
-  Операция вернула duplicate/exist, но объект не найден в state_out
-```
-
-**Причина**
-
-Пользователь `extra_user1` был создан Nubes API на предыдущей (упавшей) попытке apply.
-Terraform state не зафиксировал успех (т.к. apply завершился ошибкой), но Nubes
-счётной записью `extra_user1` не удалил.
-
-Флаг `adopt_existing_on_create = true` должен был решить это, но он проверяет
-`state_out` инстанса — а там пользователь не отражается (из-за ERR-PG-02:
-`vault_secrets` изменялся и инстанс был в "changed outside" состоянии).
-
-**Решение**
-
-Полный `terraform destroy` для очистки state + ресурсов в API, затем
-`terraform apply` с уже включённым `lifecycle { ignore_changes = [vault_secrets] }`.
-После этого проблема не воспроизводится.
-
----
-
-### ERR-PG-06: Второй пользователь на инстансе не может получить vault_secrets
-
-**Симптом**
-
-При создании второго пользователя на PG-инстансе (первый уже существует):
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_user.test_extra_user1
-  операция 4D816F17-F43E-4062-AE37-5098ADE07041 завершилась с ошибкой:
-  Секрет для пользователя test_eu1 не был создан
-```
-
-Ресурс висит ~3–4 минуты, затем падает с этой ошибкой. Воспроизводится стабильно
-для любого второго пользователя (проверено на `extra_user1`, `test_eu1`)
-независимо от роли (`ddl_user`), имени и порядка depends_on.
-
-**Важно**: `pg_test_user` (первый пользователь, созданный при инициализации
-инстанса) всегда успешно проходит через adoption за 1 секунду — его vault_secret
-уже был создан при первом apply. Только создание **нового** второго пользователя
-всегда приводит к этой ошибке.
-
-**Причина**
-
-Vault backend для PG-инстанса `e0e74801` (тест-окружение `k8s-3-sandbox-nubes-ru`)
-вероятно ограничен одной vault-записью на инстанс. При попытке создать vault_secrets
-для второго пользователя — запись не создаётся, провайдер возвращает ошибку через
-~3–4 минуты ожидания.
-
-Либо vault policy для данного инстанса предусмотрена только для основного
-пользователя (`user0`). Дополнительные пользователи не имеют прав vault-path.
-
-**Статус: открытая проблема, требует диагностики на стороне Nubes.**
-
-**Следствие для архитектуры**:
-В текущем тест-окружении Nubes PostgreSQL поддерживает **только одного пользователя
-с vault_secrets** на инстанс. Lifecycle-тесты с несколькими пользователями
-(**goal** текущей сессии) — **невозможны** без исправления vault-конфигурации.
-
-**Файл:** [examples/PG_TEST/postgres_extra.tf](examples/PG_TEST/postgres_extra.tf)
-
----
-
-### ERR-PG-07: HTTP 408 от IAM API (auth-api-test.ngcloud.ru)
-
-**Симптом**
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_user.pg_test_user
-  ошибка API 408: {"IAM URL":"https://auth-api-test.ngcloud.ru/api/v1/auth/user",
-  "idpResponse":{"prefix":{"status_text":"Request Time-out","statuscode":"408 Request Time-out"}}}
-```
-
-Может проявляться даже на этапе `terraform plan` (refresh инстанса).
-
-**Причина**
-
-Транзитная перегрузка тест-IAM-сервиса `auth-api-test.ngcloud.ru`. Возникает
-после серии интенсивных apply/destroy в течение одного или нескольких часов.
-
-**Решение**
-
-Подождать 5–10 минут и повторить apply. Ошибка проходит самостоятельно.
-
-**Важно**: в production окружении (`auth-api.ngcloud.ru`) эта проблема
-предположительно не воспроизводится.
-
----
-
-## 2026-04-03 — Коррекции и новые находки (PostgreSQL续)
-
-### ERR-PG-02: id=(known after apply) при Update — ИСПРАВЛЕНО ✅
-
-**Статус обновления**: Проблема уже решена в текущей версии провайдера.
-
-**Где было**: `internal/provider/postgres_resource.go` Update() метод устанавливал `id = (known after apply)`
-
-**Как исправлено**: Строка ~845 добавлена явная сохранение ID:
-```go
-// fix: plan.ID is Computed (empty in plan), must preserve existing ID from state
-plan.ID = state.ID
-```
-
-**Проверка**: `terraform plan` больше НЕ показывает destroy+recreate зависимых ресурсов.  
-**Результат плана (ответно)**: `Plan: 0 to add, 1 to change, 0 to destroy` (только update, без replace)
-
-**Вывод**: ERR-PG-02 не актуален для текущей версии провайдера.
-
----
-
-### ERR-PG-06: Второй пользователь — ПЕРЕКВАЛИФИЦИРОВАНО 🔄
-
-**Изменение статуса**: ERR-PG-06 была НЕВЕРНО диагностирована.
-
-**Что было думано**: "Vault backend ограничен одним пользователем на инстанс"
-
-**Что обнаружено**: `pg_test_user3` (u3) успешно создан в terraform state! Это второй пользователь на инстансе `pg-test-02`.
-
-**Проверки**:
-```bash
-terraform state list
-# Output:
-# nubes_postgres.pg_test_instance
-# nubes_postgres_user.pg_test_user         ← user0
-# nubes_postgres_user.pg_test_user3        ← u3 (УСПЕШНО)
-```
-
-**Статус**: Многопользовательское создание **РАБОТАЕТ** при правильной последовательности `depends_on`.
-
-**Реальная проблема**: Не в создании пользователей, а в том что файл `postgres_extra.tf` с третьим пользователем был переименован в `postgres_extra.tf11` (бэкап), и текущий конфиг не имел этого файла.
-
-**Вывод**: ERR-PG-06 была следствием неполного тестирования, а не действительным ограничением API.
-
----
-
-### ERR-PG-08: Concurrent Operations Are Not Supported ❌ НОВАЯ ПРОБЛЕМА
-
-**Симптом**
-
-После успешного завершения Update операции на `nubes_postgres`, попытка создать
-зависимый ресурс (например БД) немедленно падает с ошибкой 422:
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_database.pg_test_db
-  ошибка API 422: {
-    "DETAIL": "There is a started operation on this instance",
-    "TYPE": "about:blank",
-    "TITLE": "Concurrent operations are not supported (job status: SUCCESS)"
-  }
-```
-
-**Когда воспроизводится**
-1. `terraform plan` обнаруживает изменения (например, `vault_secrets` drift)
-2. Apply запускает Update инстанса: `nubes_postgres.pg_test_instance: Modifying...`
-3. Update успешно завершается: `Modifications complete after 0s`
-4. Terraform пытается создать DB: `nubes_postgres_database.pg_test_db: Creating...`
-5. **FAIL**: 422 Concurrent operations
-
-**Попытки обхода (неуспешные)**
-- Добавлен `depends_on = [pg_test_user3]` — не помогло ✗
-- Ожидание 60 секунд между apply'ами — не помогло ✗
-- Ожидание 120 секунд — не помогло ✗
-
-**Причина**
-
-Nubes API имеет встроенный serial-lock на операции per-instance. Даже хотя
-`WaitForOperation()` возвращает `IsSuccessful = true`, сервер всё ещё обрабатывает
-асинхронные побочные эффекты (Vault sync, state reconciliation и тд). Новые запросы
-на операции отклоняются с 422 до полного завершения.
-
-**Текущий workaround**
-
-Разбить apply на несколько фаз вручную:
-```bash
-# Фаза 1: создание инстанса + пользователей (без БД)
-cp postgres.tf postgres.tf.bak
-sed -i '/resource.*nubes_postgres_database/,/^}/d' postgres.tf
-terraform apply -auto-approve
-
-# Фаза 2: добавить БД обратно и применить
-cp postgres.tf.bak postgres.tf
-terraform apply -auto-approve
-```
-
-**Статус**: Открытая проблема в провайдере. Требует fix на уровне `WaitForOperation()`.
-
-**Рекомендуемое решение**: Добавить post-completion delay (30–60 сек) или retry mechanism
-в `internal/provider/client_impl.go` метод `WaitForOperation`.
-
-**Файл для анализа**: [`internal/provider/client_impl.go` line 240+](../../terra/terraform/internal/provider/client_impl.go#L240)
-
-**Документация**: [ERR-PG-08-concurrent-operations.md](ERR-PG-08-concurrent-operations.md)
-
----
-
-## 2026-03-29 — SSH timeout после destroy VM example
-
-### Симптом
-
-После `terraform destroy` для [examples/VM](examples/VM) попытка зайти по SSH на target VM завершилась таймаутом:
-
-- `ssh: connect to host 185.247.187.154 port 22: Connection timed out`
-
-### Причина
-
-Это ожидаемое поведение для сценария suspend: VM перестаёт отвечать по SSH после destroy, а затем поднимается обратно на `terraform apply`.
-
-### Что сделали
-
-- Подтвердили, что `terraform apply` после destroy восстанавливает доступ и повторно запускает install jobs.
-
----
-
-## 2026-03-26 — БАГ ГЕНЕРАТОРА: modify-only поля помечаются Required в schema ресурса
-
-```
-Error: Missing required argument
-  on vc_org.tf line 5, in resource "nubes_vc_org" "dev_org":
-   5: resource "nubes_vc_org" "dev_org" {
-The argument "v_i_p_configure" is required, but no definition was found.
-The argument "resource_name" is required, but no definition was found.
-```
-
-### Причина
-
-Генератор (`~/terra/terraform/devops/`) при создании Go-кода ресурса (`19_vc_org_resource.go`)
-помечает **все операции ресурса** как `Required` в схеме, включая поля,
-которые нужны только для операции `modify` (не для `create`).
-
-Конкретный пример: `vIPConfigure` (код параметра 662) — это поле операции `modify`,
-но попадает в schema с `Required: true`:
-
-```go
-"v_i_p_configure": schema.StringAttribute{Required: true},
-```
-
-В YAML-описании сервиса (19_vc_org.yaml) `vIPConfigure` объявлен только под
-`operations.modify.params`, а не под `operations.create.params`.
-
-### Что нужно исправить в генераторе
-
-В `~/terra/terraform/devops/` (файлы `02_generate_resources_and_docs*.go/sh`):
-
-Поля, принадлежащие только операции `modify` (или другим не-create операциям),
-должны генерироваться как **`Optional: true, Computed: true`**, а не `Required: true`.
-
-Логика:
-- поле в `operations[create].params` → `Required: true`
-- поле только в `operations[modify].params` → `Optional: true, Computed: true`
-- поле только в state (read-only) → `Computed: true`
-
-### Временный workaround (действующий)
-
-В `terraform.tf`-манифесте указывать пустую строку:
-
-```hcl
-v_i_p_configure = ""   # modify-only поле; при create не отправляется в API
-```
-
-Провайдер при Create не передаёт это поле в API (строка 418/556 params),
-но schema.Required требует non-null значение в плане.
-
-### Файлы для правки
-
-- `~/terra/terraform/devops/profiles/test/generated/go/19_vc_org_resource.go` — сгенерированный, не менять вручную
-- **Править нужно шаблоны/генераторы** в `~/terra/terraform/devops/`
-
----
-
 ## 2026-03-22 — БАГ: CreateService/CreateFunction возвращает 409 при `terraform apply -replace` (ИСПРАВЛЕН)
 
 ### Симптом

doc/infrastructure/pg-test.md

@@ -1,193 +0,0 @@
-# PG_TEST — инфраструктура тестирования Nubes PostgreSQL
-
-Создан: 2026-04-01
-
----
-
-## Цель
-
-Набор Terraform-манифестов для тестирования провайдера `nubes` (ресурсы PostgreSQL).
-Покрывает: создание инстанса, управление пользователями и базами данных, lifecycle-операции.
-
-Также используется как шаблон для передачи заказчикам — достаточно вписать
-`api_token`, `s3_uid`, `realm` в `terraform.tfvars`.
-
----
-
-## Расположение
-
-| Место | Путь |
-|---|---|
-| Локально | `/home/naeel/remote_dev/sless/examples/PG_TEST/` |
-| На VM | `/home/naeel/terra/sless/examples/PG_TEST/` |
-| VM | `naeel@5.172.178.213` |
-| SSH-ключ | `secrets/naeel_vm_id_ed25519` |
-
-> **Правило:** все `terraform` команды выполняются только на VM через SSH.
-> Локально — только редактирование файлов + `scp` для синхронизации.
-
----
-
-## Файловая структура
-
-```
-examples/PG_TEST/
-├── main.tf                   # провайдер nubes + переменные
-├── postgres.tf               # инстанс + базовый пользователь + база
-├── postgres_extra.tf         # доп. пользователи и базы для lifecycle-тестов
-├── outputs.tf                # host, port, user, password, DSN
-├── terraform.tfvars          # рабочие значения (не в git, токен и IDs)
-├── terraform.tfvars.example  # шаблон для заказчика (masked placeholders)
-└── test_lifecycle.sh         # скрипт последовательного lifecycle-тестирования
-```
-
----
-
-## Провайдер
-
-```hcl
-terraform {
-  required_providers {
-    nubes = {
-      source  = "terra.k8c.ru/nubes/nubes"
-      version = "5.0.51"
-    }
-  }
-}
-
-provider "nubes" {
-  api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
-  api_token    = var.api_token
-}
-```
-
----
-
-## Ресурсы
-
-### nubes_postgres (pg_test_instance)
-
-- `resource_name = "pg-test-02"`
-- `resource_realm = "k8s-3-sandbox-nubes-ru"`
-- `app_version = "17"` (PostgreSQL 17)
-- CPU: 500m, Memory: 512 MiB, Disk: 1 GiB
-- `adopt_existing_on_create = true`
-- `operation_timeout = "11m"`
-- **`lifecycle { ignore_changes }`** — не решает проблему с `vault_secrets` (см. ERR-PG-02)
-
-Инстанс ID: `e0e74801-d68e-4637-8ef3-d846b289846e`
-
-### nubes_postgres_user
-
-- Рабочая роль: **только `ddl_user`** (роль `app_user` не работает — ERR-PG-04)
-- `adopt_existing_on_create = true`
-- Пользователи создаются **строго последовательно** через `depends_on` (ERR-PG-03)
-
-### nubes_postgres_database
-
-- `adopt_existing_on_create = true`
-- `db_owner` = username из `nubes_postgres_user`
-- Создаётся после всех пользователей которые будут db_owner (через `depends_on`)
-
----
-
-## Обязательная цепочка depends_on
-
-Nubes API не поддерживает параллельные операции на одном PG инстансе.
-Нарушение вызывает race condition в Vault (ERR-PG-03).
-
-```
-nubes_postgres
-  └─→ pg_test_user (ddl_user)
-        └─→ pg_test_db  (owner=pg_test_user)
-              └─→ test_extra_user1 (ddl_user)
-                    └─→ test_extra_user2 (ddl_user)
-                          └─→ test_extra_db1 (owner=extra_user1)
-                                └─→ test_extra_db2 (owner=extra_user2)
-```
-
----
-
-## Переменные (terraform.tfvars)
-
-| Переменная | Описание | Пример |
-|---|---|---|
-| `api_token` | JWT токен Nubes API | `eyJ...` |
-| `s3_uid` | UUID S3 bucket для бэкапов PG | `332cdb0d-...` |
-| `realm` | realm кластера | `k8s-3-sandbox-nubes-ru` |
-| `pg_resource_name` | имя PG инстанса | `pg-test-02` |
-| `pg_username` | имя основного пользователя | `user0` |
-| `pg_db_name` | имя основной базы данных | `db0` |
-| `pg_role` | роль основного пользователя | `ddl_user` |
-
----
-
-## Команды
-
-Все команды — через SSH на VM:
-
-```bash
-SSH="ssh -i /home/naeel/remote_dev/sless/secrets/naeel_vm_id_ed25519 -o StrictHostKeyChecking=no naeel@5.172.178.213"
-TF="cd /home/naeel/terra/sless/examples/PG_TEST &&"
-
-# Применить конфигурацию
-$SSH "$TF terraform apply -auto-approve"
-
-# Проверить state
-$SSH "$TF terraform state list"
-
-# Посмотреть outputs
-$SSH "$TF terraform output"
-
-# Удалить все ресурсы
-$SSH "$TF terraform destroy -auto-approve"
-```
-
-Синхронизация файлов на VM:
-
-```bash
-scp -i secrets/naeel_vm_id_ed25519 examples/PG_TEST/postgres.tf \
-    naeel@5.172.178.213:/home/naeel/terra/sless/examples/PG_TEST/postgres.tf
-```
-
----
-
-## Известные ограничения API
-
-| # | Проблема | Статус |
-|---|---|---|
-| ERR-PG-01 | `json_parameters` — "Invalid JSON String" | обойдено: убран параметр |
-| ERR-PG-02 | `vault_secrets` обновляется вне TF | открытая проблема: `ignore_changes` не эффективен |
-| ERR-PG-03 | Race condition при параллельном создании users | обойдено: `depends_on` chain |
-| ERR-PG-04 | Роль `app_user` — "Секрет не был создан" | не работает, используем только `ddl_user` |
-| ERR-PG-05 | "Нарушена консистентность" при stale state | решение: `terraform destroy` + rebuild |
-
-Подробности: [doc/errors/log.md](doc/errors/log.md)
-
----
-
-## Ожидаемые времена операций
-
-| Операция | Примерное время |
-|---|---|
-| Создание `nubes_postgres_user` | ~50–75 секунд |
-| Удаление `nubes_postgres_user` | ~56–76 секунд |
-| Создание `nubes_postgres_database` | ~47–70 секунд |
-| Удаление `nubes_postgres_database` | ~46–92 секунды |
-| Обновление `nubes_postgres` in-place | мгновенно (~0s) |
-
-Полный `apply` с 6 новыми ресурсами занимает **~8–12 минут**.
-
----
-
-## Lifecycle-тест (test_lifecycle.sh)
-
-Скрипт тестирует последовательность операций:
-
-1. **Создать всё** — apply базовой конфигурации + extra
-2. **Удалить user2 + db2** — закомментировать ресурсы, apply
-3. **Воссоздать** — раскомментировать, apply
-4. **Сменить db_owner** — extra_db1.owner: extra_user1 → extra_user2
-5. **Невалидные параметры** — db_owner = несуществующий пользователь (ожидать ошибку API)
-
-Запуск: `$SSH "cd /home/naeel/terra/sless/examples/PG_TEST && bash test_lifecycle.sh"`

doc/iot-mvp-plan.md

@@ -1,739 +0,0 @@
-# IoT MVP — План реализации для Sonnet
-
-> **Автор плана**: GitHub Copilot (Claude Opus 4.6)  
-> **Дата**: 2026-04-04  
-> **Исполнитель**: Claude Sonnet  
-> **Ход рассуждений**: `doc/thinking/2026-04-04.md`
-
----
-
-## Контекст
-
-Платформа **sless** — managed serverless functions. Нужно добавить **managed IoT service** как демо с возможностью усложнения.
-
-### Согласованные решения
-
-| Вопрос | Решение | Обоснование |
-|--------|---------|-------------|
-| Репозиторий | Та же репа, код в `iot/` | Легко вынести потом, удобно для демо |
-| Message broker IoT | RabbitMQ (MVP), потом Kafka | RabbitMQ уже есть, архитектура broker-agnostic |
-| Message broker sless | RabbitMQ (не трогать) | Работает, отдельный fault domain |
-| MQTT-брокер | EMQX, деплой plain YAML | Не Helm, не Operator — достаточно для демо |
-| IoT-логика | CRD + controller (Go operator) | Консистентно с sless, сразу правильно |
-| Terraform | Расширяем текущий sless provider | Для демо ОК, переименование потом |
-| Device auth | EMQX HTTP Auth Backend → наш API | Динамическое добавление устройств |
-
-### Что НЕ делаем (отложено)
-
-- Device Shadow / Digital Twin
-- Rules Engine (для демо — простая маршрутизация topic→queue)
-- Time-series storage (функция сама пишет в Postgres)
-- Cloud→Device commands
-- Client certificates (для демо: username/password)
-- Dashboard
-
----
-
-## Существующая архитектура (НЕ ТРОГАТЬ)
-
-```
-Go module: gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless
-API Group: sless.kube5s.ru/v1alpha1
-Namespace pattern: sless-{sha256(jwt.sub)[:16]}
-
-Контроллеры (main.go, строки 153-184):
-  - FunctionReconciler
-  - ServiceReconciler
-  - TriggerReconciler
-  - FunctionJobReconciler
-
-API-сервер: internal/api/router.go (gorilla/mux), порт cfg.APIPort
-  - JWT auth middleware → namespace validation
-  - Routes: /v1/namespaces/{namespace}/functions|services|triggers|jobs
-
-Trigger types: "http", "cron", "event" (api/v1alpha1/trigger_types.go)
-Event-dispatcher: services/event-dispatcher/ (AMQP consumer → POST в функцию)
-RabbitMQ: deployments/k8s/rabbitmq.yaml (namespace: sless)
-```
-
----
-
-## Целевая архитектура MVP
-
-```
-IoT Device
-  → MQTT connect (username=deviceId, password=deviceSecret)
-  → EMQX (topic: {namespace}/telemetry/{deviceId})
-    → EMQX RabbitMQ Bridge → RabbitMQ (queue: iot.{namespace})
-      → event-dispatcher (существующий!) → POST → serverless function
-        → function обрабатывает данные
-
-Аутентификация устройств:
-  EMQX HTTP Auth Plugin → GET http://sless-iot-auth.sless.svc:8080/mqtt/auth
-    → проверка credentials из k8s Secret → ACL (только свой namespace в topics)
-```
-
----
-
-## Этапы реализации
-
-### Этап 1: CRD IoTDevice и контроллер
-
-**Цель**: зарегистрировать IoT-устройство через CRD, автоматически создать credentials.
-
-#### 1.1. Создать CRD типы
-
-Файл: `iot/api/v1alpha1/device_types.go`
-
-```go
-package v1alpha1
-
-import (
-    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
-)
-
-// IoTDeviceSpec — спецификация IoT-устройства
-type IoTDeviceSpec struct {
-    // DeviceID — уникальный идентификатор устройства внутри namespace
-    DeviceID string `json:"deviceId"`
-    
-    // Metadata — произвольные метаданные устройства (модель, локация и т.д.)
-    // +optional
-    Metadata map[string]string `json:"metadata,omitempty"`
-    
-    // Enabled — активно ли устройство (может подключаться к MQTT)
-    // +kubebuilder:default=true
-    Enabled bool `json:"enabled"`
-}
-
-// IoTDeviceStatus — статус IoT-устройства
-type IoTDeviceStatus struct {
-    // Phase — текущее состояние: Pending, Active, Disabled, Error
-    Phase string `json:"phase,omitempty"`
-    
-    // MQTTUsername — имя пользователя для подключения к MQTT
-    MQTTUsername string `json:"mqttUsername,omitempty"`
-    
-    // SecretName — имя k8s Secret с credentials
-    SecretName string `json:"secretName,omitempty"`
-    
-    // TopicPrefix — разрешённый prefix для MQTT topics
-    TopicPrefix string `json:"topicPrefix,omitempty"`
-    
-    // LastConnected — время последнего подключения (заполняется auth-сервисом)
-    // +optional
-    LastConnected *metav1.Time `json:"lastConnected,omitempty"`
-    
-    // Message — человекочитаемое сообщение о статусе
-    Message string `json:"message,omitempty"`
-}
-
-// +kubebuilder:object:root=true
-// +kubebuilder:subresource:status
-// +kubebuilder:printcolumn:name="DeviceID",type=string,JSONPath=`.spec.deviceId`
-// +kubebuilder:printcolumn:name="Phase",type=string,JSONPath=`.status.phase`
-// +kubebuilder:printcolumn:name="Enabled",type=boolean,JSONPath=`.spec.enabled`
-type IoTDevice struct {
-    metav1.TypeMeta   `json:",inline"`
-    metav1.ObjectMeta `json:"metadata,omitempty"`
-    Spec   IoTDeviceSpec   `json:"spec,omitempty"`
-    Status IoTDeviceStatus `json:"status,omitempty"`
-}
-
-// +kubebuilder:object:root=true
-type IoTDeviceList struct {
-    metav1.TypeMeta `json:",inline"`
-    metav1.ListMeta `json:"metadata,omitempty"`
-    Items           []IoTDevice `json:"items"`
-}
-```
-
-Файл: `iot/api/v1alpha1/groupversion_info.go`
-
-```go
-package v1alpha1
-
-import (
-    "k8s.io/apimachinery/pkg/runtime/schema"
-    "sigs.k8s.io/controller-runtime/pkg/scheme"
-)
-
-var (
-    // GroupVersion — API group для IoT ресурсов
-    // ВАЖНО: отдельный group от sless.kube5s.ru — для будущего разделения
-    GroupVersion = schema.GroupVersion{Group: "iot.kube5s.ru", Version: "v1alpha1"}
-    
-    SchemeBuilder = &scheme.Builder{GroupVersion: GroupVersion}
-    AddToScheme   = SchemeBuilder.AddToScheme
-)
-
-func init() {
-    SchemeBuilder.Register(&IoTDevice{}, &IoTDeviceList{})
-}
-```
-
-**ВАЖНО**: API group `iot.kube5s.ru` — отдельная от `sless.kube5s.ru`. Причина: при разделении на отдельную репу CRD не будет конфликтовать.
-
-#### 1.2. Сгенерировать deepcopy и CRD манифесты
-
-```bash
-# Из корня проекта:
-controller-gen object paths=./iot/api/v1alpha1/...
-controller-gen crd paths=./iot/api/v1alpha1/... output:crd:dir=iot/config/crd/bases
-```
-
-#### 1.3. Создать контроллер IoTDevice
-
-Файл: `iot/controllers/iotdevice_controller.go`
-
-Логика Reconcile:
-1. Получить IoTDevice из пришедшего запроса
-2. Если `DeletionTimestamp != nil` → удалить Secret, убрать finalizer
-3. Добавить finalizer `iot.kube5s.ru/device-cleanup` если нет
-4. Если `spec.enabled == false`:
-   - Установить `status.phase = "Disabled"`
-   - НЕ удалять Secret (устройство может быть включено обратно)
-5. Если Secret не существует:
-   - Сгенерировать пароль (32 байта crypto/rand → hex)
-   - MQTTUsername = `{namespace}_{deviceId}` (namespace включён для уникальности MQTT username)
-   - Создать Secret `iot-{deviceId}` в том же namespace с полями:
-     - `mqtt-username`: `{namespace}_{deviceId}`
-     - `mqtt-password`: сгенерированный пароль
-   - Установить OwnerReference на IoTDevice (каскадное удаление)
-6. Заполнить status:
-   - `phase = "Active"` (или "Disabled" если !enabled)
-   - `mqttUsername = {namespace}_{deviceId}`
-   - `secretName = iot-{deviceId}`
-   - `topicPrefix = {namespace}/` (устройство может публиковать только в topics с этим prefix)
-
-#### 1.4. Зарегистрировать контроллер в main.go
-
-Добавить в `main.go` после существующих SetupWithManager вызовов:
-
-```go
-if err = (&iotcontrollers.IoTDeviceReconciler{
-    Client: mgr.GetClient(),
-    Scheme: mgr.GetScheme(),
-    Log:    ctrl.Log.WithName("controllers").WithName("IoTDevice"),
-}).SetupWithManager(mgr); err != nil {
-    setupLog.Error(err, "unable to create controller", "controller", "IoTDevice")
-    os.Exit(1)
-}
-```
-
-Добавить в import:
-```go
-iotv1alpha1 "gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/api/v1alpha1"
-iotcontrollers "gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/controllers"
-```
-
-Добавить schema registration в init/scheme:
-```go
-utilruntime.Must(iotv1alpha1.AddToScheme(scheme))
-```
-
----
-
-### Этап 2: MQTT Auth Service
-
-**Цель**: EMQX при каждом MQTT CONNECT проверяет credentials через наш HTTP-сервис.
-
-#### 2.1. Создать auth handler
-
-Файл: `iot/internal/mqttauth/mqtt_auth_handler.go`
-
-HTTP-сервис, отдельный порт (например 8081) или sub-router в основном API.
-
-**Эндпоинт**: `POST /mqtt/auth` (вызывается EMQX HTTP Auth Plugin)
-
-EMQX присылает JSON:
-```json
-{
-  "username": "sless-abc123def456_sensor-01",
-  "password": "hex-encoded-secret",
-  "clientid": "...",
-  "peerhost": "10.0.0.5"
-}
-```
-
-Логика:
-1. Распарсить username: `{namespace}_{deviceId}`
-2. Найти Secret `iot-{deviceId}` в namespace `{namespace}`
-3. Сравнить password с `mqtt-password` из Secret (constant-time comparison!)
-4. Если совпало:
-   - Проверить что IoTDevice существует и `enabled == true`
-   - Вернуть 200 + JSON с ACL:
-     ```json
-     {
-       "result": "allow",
-       "is_superuser": false,
-       "acl": [
-         {"permission": "allow", "action": "publish", "topic": "{namespace}/#"},
-         {"permission": "allow", "action": "subscribe", "topic": "{namespace}/#"},
-         {"permission": "deny", "action": "all", "topic": "#"}
-       ]
-     }
-     ```
-5. Если не совпало → вернуть 200 + `{"result": "deny"}`
-
-**ВАЖНО**: НЕ возвращать 401/403 — EMQX интерпретирует HTTP-ошибки как "ignore this backend, try next". Всегда 200, result = "allow"/"deny".
-
-#### 2.2. Запустить auth-сервис
-
-Два варианта (решить при реализации):
-- **Вариант A**: отдельный binary `iot/cmd/mqtt-auth/main.go` + Deployment
-- **Вариант B**: добавить route в существующий API-сервер (проще для демо)
-
-Для демо — **вариант B**: добавить роут `/internal/mqtt/auth` в `internal/api/router.go`. Prefix `/internal/` = не защищён JWT (доступен только из кластера).
-
----
-
-### Этап 3: Развёртывание EMQX
-
-**Цель**: MQTT-брокер, принимающий подключения от IoT-устройств.
-
-#### 3.1. Создать YAML
-
-Файл: `deployments/k8s/emqx.yaml`
-
-По аналогии с `deployments/k8s/rabbitmq.yaml`:
-
-```yaml
-# Деплой EMQX MQTT-брокера для IoT-сервиса
-# 2026-04-04
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: emqx-config
-  namespace: sless
-data:
-  # HTTP Auth Backend — аутентификация устройств через наш API
-  EMQX_AUTH__HTTP__AUTH_REQ__URL: "http://sless-api.sless.svc:8080/internal/mqtt/auth"
-  EMQX_AUTH__HTTP__AUTH_REQ__METHOD: "post"
-  EMQX_AUTH__HTTP__AUTH_REQ__CONTENT_TYPE: "json"
-  
-  # RabbitMQ Bridge (MVP) — маршрутизация MQTT → RabbitMQ
-  # ПОТОМ заменится на Kafka bridge — только этот ConfigMap
-  EMQX_BRIDGE__RABBIT__SERVER: "amqp://sless:sless123@rabbitmq.sless.svc.cluster.local:5672"
----
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: emqx
-  namespace: sless
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: emqx
-  template:
-    metadata:
-      labels:
-        app: emqx
-    spec:
-      containers:
-      - name: emqx
-        image: emqx/emqx:5.5.1
-        ports:
-        - name: mqtt
-          containerPort: 1883
-        - name: mqttssl
-          containerPort: 8883
-        - name: ws
-          containerPort: 8083
-        - name: dashboard
-          containerPort: 18083
-        resources:
-          requests:
-            memory: "256Mi"
-            cpu: "100m"
-          limits:
-            memory: "512Mi"
-            cpu: "500m"
-        envFrom:
-        - configMapRef:
-            name: emqx-config
-        readinessProbe:
-          tcpSocket:
-            port: 1883
-          initialDelaySeconds: 15
-          periodSeconds: 10
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: emqx
-  namespace: sless
-spec:
-  selector:
-    app: emqx
-  ports:
-  - name: mqtt
-    port: 1883
-    targetPort: 1883
-  - name: ws
-    port: 8083
-    targetPort: 8083
-  - name: dashboard
-    port: 18083
-    targetPort: 18083
-```
-
-**ВНИМАНИЕ**: конфиг EMQX 5.x сильно отличается от 4.x. При реализации:
-- Проверить актуальный формат env-переменных для EMQX 5.5
-- HTTP Auth Plugin в EMQX 5 конфигурируется через Dashboard API или файл `etc/emqx.conf`
-- Возможно понадобится volume mount для `emqx.conf` вместо env
-
-#### 3.2. Настроить EMQX Rule + RabbitMQ Bridge
-
-EMQX Rule Engine (конфигурируется через EMQX HTTP API или Dashboard):
-
-```
-Rule SQL:
-  SELECT * FROM '{namespace}/+/+'
-  
-Action:
-  Bridge to RabbitMQ
-  Exchange: amq.topic
-  Routing Key: iot.{namespace}
-  Queue: iot.{namespace}.telemetry
-```
-
-Для MVP — можно сконфигурировать одно правило вручную или через EMQX REST API при старте (init-container или наш контроллер).
-
-**ВАЖНО для Sonnet**: EMQX 5.x использует `bridges` API — изучить документацию EMQX 5.5:
-- `POST /api/v5/bridges` — создание bridge
-- `POST /api/v5/rules` — создание правил
-- Или файл `etc/emqx.conf` (HOCON формат)
-
----
-
-### Этап 4: API-эндпоинты для IoT
-
-**Цель**: REST API для управления устройствами (Terraform provider будет вызывать их).
-
-#### 4.1. Добавить IoT-роуты в router.go
-
-Файл: `internal/api/router.go`
-
-Новые routes (защищены JWT, как существующие):
-```
-POST   /v1/namespaces/{namespace}/iot/devices       → CreateIoTDevice
-GET    /v1/namespaces/{namespace}/iot/devices        → ListIoTDevices
-GET    /v1/namespaces/{namespace}/iot/devices/{name} → GetIoTDevice
-DELETE /v1/namespaces/{namespace}/iot/devices/{name} → DeleteIoTDevice
-PATCH  /v1/namespaces/{namespace}/iot/devices/{name} → UpdateIoTDevice (enable/disable)
-```
-
-Internal route (без JWT, только для EMQX из кластера):
-```
-POST   /internal/mqtt/auth → MQTTAuth
-```
-
-#### 4.2. Создать IoT handler
-
-Файл: `iot/internal/api/iot_device_handler.go` (или добавить в `internal/api/handler/`)
-
-Хендлеры = тонкая обёртка над k8s API:
-- `CreateIoTDevice`: создаёт IoTDevice CRD объект → контроллер reconcile → Secret
-- `GetIoTDevice`: читает IoTDevice CRD + возвращает credentials из Secret
-- `DeleteIoTDevice`: удаляет IoTDevice CRD → контроллер cleanup через finalizer
-- `ListIoTDevices`: list IoTDevice в namespace
-- `UpdateIoTDevice`: patch spec.enabled
-
-**GET /devices/{name}** должен возвращать credentials (mqtt_username, mqtt_password) из Secret. Они нужны пользователю для конфигурации устройства. Credentials возвращаются **только при GET**, не хранятся в CRD status.
-
----
-
-### Этап 5: Связь MQTT → Serverless Function
-
-**Цель**: IoT-устройство отправляет MQTT → вызывается serverless function.
-
-#### 5.1. Цепочка
-
-Пользователь создаёт через Terraform:
-1. `sless_iot_device` → IoTDevice CRD → MQTT credentials
-2. `sless_function` → Function → готовая serverless функция
-3. `sless_trigger` type=event, queue="iot.{namespace}.telemetry" → event-dispatcher подписывается
-
-Event-dispatcher (уже работает!) читает из RabbitMQ queue → POST в функцию.
-
-#### 5.2. Автоматическое создание RabbitMQ queue
-
-IoT-контроллер при reconcile должен обеспечить (ensure) существование queue `iot.{namespace}.telemetry` в RabbitMQ. 
-
-Варианты:
-- **A**: Контроллер создаёт queue через RMQ Management API (HTTP) — явно
-- **B**: Queue создаётся автоматически EMQX bridge + event-dispatcher consumer (declare on consume)
-
-Для MVP — **вариант B**: и EMQX bridge, и event-dispatcher делают QueueDeclare — кто первый, тот и создаст. Дурак-proof.
-
----
-
-### Этап 6: Terraform Provider
-
-**Цель**: управление IoT-устройствами через Terraform.
-
-Terraform provider sless находится в **отдельной репе**. Нужно расширить его.
-
-Новый ресурс: `sless_iot_device`
-
-```hcl
-resource "sless_iot_device" "sensor_01" {
-  namespace = sless_namespace.my_ns.name
-  name      = "temperature-sensor"
-  device_id = "sensor-01"
-  enabled   = true
-  
-  metadata = {
-    model    = "DHT22"
-    location = "room-1"
-  }
-}
-
-output "mqtt_username" {
-  value = sless_iot_device.sensor_01.mqtt_username
-}
-
-output "mqtt_password" {
-  value     = sless_iot_device.sensor_01.mqtt_password
-  sensitive = true
-}
-```
-
-CRUD маппинг:
-- Create → `POST /v1/namespaces/{ns}/iot/devices`
-- Read → `GET /v1/namespaces/{ns}/iot/devices/{name}`
-- Update → `PATCH /v1/namespaces/{ns}/iot/devices/{name}`
-- Delete → `DELETE /v1/namespaces/{ns}/iot/devices/{name}`
-
----
-
-### Этап 7: E2E Demo
-
-**Цель**: показать полную цепочку device → function.
-
-#### Demo Terraform:
-
-```hcl
-# 1. Функция-обработчик IoT данных
-resource "sless_function" "iot_handler" {
-  namespace  = var.namespace
-  name       = "iot-handler"
-  runtime    = "python3.11"
-  source_dir = "./iot-handler"
-}
-
-# 2. Event trigger: подписка на IoT queue
-resource "sless_trigger" "iot_events" {
-  namespace    = var.namespace
-  name         = "iot-telemetry"
-  type         = "event"
-  function_ref = sless_function.iot_handler.name
-  queue        = "iot.${var.namespace}.telemetry"
-  enabled      = true
-}
-
-# 3. IoT устройство
-resource "sless_iot_device" "sensor" {
-  namespace = var.namespace
-  name      = "demo-sensor"
-  device_id = "sensor-001"
-  enabled   = true
-}
-
-output "mqtt_host" {
-  value = "emqx.sless.svc.cluster.local"
-}
-output "mqtt_username" {
-  value = sless_iot_device.sensor.mqtt_username
-}
-output "mqtt_password" {
-  value     = sless_iot_device.sensor.mqtt_password
-  sensitive = true
-}
-```
-
-#### Demo Python IoT handler (`iot-handler/handler.py`):
-
-```python
-def handler(event, context):
-    """Обработчик IoT-телеметрии. Вызывается event-dispatcher при новом MQTT сообщении."""
-    import json
-    data = json.loads(event["body"])
-    print(f"Telemetry from device: {data}")
-    return {"statusCode": 200, "body": json.dumps({"processed": True})}
-```
-
-#### Demo MQTT client (для тестирования):
-
-```bash
-# Отправить MQTT сообщение (mosquitto_pub)
-mosquitto_pub \
-  -h emqx.sless.svc.cluster.local \
-  -p 1883 \
-  -u "sless-abc123_sensor-001" \
-  -P "generated-password" \
-  -t "sless-abc123/telemetry/sensor-001" \
-  -m '{"temperature": 22.5, "humidity": 65}'
-```
-
----
-
-## Структура файлов (итого)
-
-```
-iot/
-  api/v1alpha1/
-    device_types.go              # CRD IoTDevice
-    groupversion_info.go         # API group iot.kube5s.ru/v1alpha1
-    zz_generated.deepcopy.go     # сгенерировано controller-gen
-  config/
-    crd/bases/                   # сгенерированные CRD YAML
-  controllers/
-    iotdevice_controller.go      # Reconcile: Secret, credentials
-  internal/
-    mqttauth/
-      mqtt_auth_handler.go       # HTTP Auth Backend для EMQX
-
-deployments/k8s/
-  emqx.yaml                     # EMQX deployment (новый файл)
-
-internal/api/
-  handler/
-    iot_devices.go               # REST handlers для IoT devices (новый файл)
-  router.go                      # + IoT routes (редактирование)
-
-main.go                          # + IoTDevice controller registration (редактирование)
-
-examples/
-  IOT/                           # Demo пример
-    main.tf
-    handler.py
-```
-
----
-
-## Порядок выполнения
-
-```
-1. CRD types + deepcopy + manifests        (iot/api/)
-2. IoTDevice controller                     (iot/controllers/)
-3. Register controller в main.go            (main.go)
-4. CRD apply в кластер                     (kubectl apply)
-5. MQTT Auth handler                        (iot/internal/mqttauth/)
-6. REST API endpoints для IoT              (internal/api/)
-7. EMQX deployment YAML                    (deployments/k8s/emqx.yaml)
-8. EMQX конфигурация (auth backend + RMQ bridge)
-9. Terraform provider resource             (отдельная репа)
-10. E2E demo                               (examples/IOT/)
-11. Тестирование: device → MQTT → function
-```
-
----
-
-## Что менять при переходе на Kafka (потом)
-
-| Компонент | Изменение |
-|-----------|-----------|
-| EMQX bridge config | `rabbitmq` → `kafka` (ConfigMap) |
-| Consumer | Новый `iot-event-consumer` (~200 строк Go) вместо event-dispatcher |
-| Kafka deploy | Managed сервис или Strimzi в кластере |
-| CRD / Controller | **БЕЗ ИЗМЕНЕНИЙ** |
-| MQTT Auth | **БЕЗ ИЗМЕНЕНИЙ** |
-| API endpoints | **БЕЗ ИЗМЕНЕНИЙ** |
-| Terraform | **БЕЗ ИЗМЕНЕНИЙ** |
-
----
-
-## Правила для Sonnet
-
-1. **Читай `doc/thinking/2026-04-04.md`** — там полный ход рассуждений и обоснования
-2. **Читай `.github/copilot-instructions.md`** — правила проекта
-3. **НЕ трогай** существующий код sless (controllers/, services/, internal/) без крайней необходимости
-4. **Комментарии обязательны** — дата, назначение функций, "почему" для нетривиальной логики
-5. **Именование** — уникальные осмысленные имена (iot_device_handler, NOT handler)
-6. **Пиши в `doc/thinking/`** свои мысли при решении
-7. **EMQX конфиг** — обязательно проверить актуальный формат для EMQX 5.5.x
-8. **Security**: constant-time password comparison, не логировать credentials, ACL-изоляция по namespace
-
----
-
-## Справка для нового агента (чтобы не искать)
-
-### Terraform provider
-- Расположен **в этой же репе**: `terraform/provider/`
-- Go module: `terraform-provider-sless` (свой go.mod: `terraform/provider/go.mod`)
-- Структура:
-  ```
-  terraform/provider/
-    main.go
-    go.mod
-    internal/
-      client/       # HTTP-клиент к sless API
-      provider/     # provider.go — регистрация ресурсов
-      resources/    # function_resource.go, trigger_resource.go, service_resource.go, job_resource.go
-    hack/
-      build-and-publish.sh
-  ```
-- Новый ресурс `sless_iot_device` добавлять в `terraform/provider/internal/resources/iot_device_resource.go`
-- Зарегистрировать в `terraform/provider/internal/provider/provider.go`
-
-### controller-gen
-- Бинарь: `bin/controller-gen` (в корне репы)
-- Генерация deepcopy: `./bin/controller-gen object paths=./iot/api/v1alpha1/...`
-- Генерация CRD: `./bin/controller-gen crd paths=./iot/api/v1alpha1/... output:crd:dir=iot/config/crd/bases`
-
-### Как зарегистрированы существующие контроллеры (пример из main.go)
-```go
-// main.go строки ~153-184
-if err = (&controllers.FunctionReconciler{
-    Client:   mgr.GetClient(),
-    Scheme:   mgr.GetScheme(),
-    S3Client: s3Client,
-    Config:   cfg,
-}).SetupWithManager(mgr); err != nil {
-    setupLog.Error(err, "unable to create controller", "controller", "Function")
-    os.Exit(1)
-}
-```
-Новый IoT контроллер регистрируется аналогично, после этого блока.
-
-### Scheme registration (main.go)
-```go
-// Существующие:
-utilruntime.Must(slessv1alpha1.AddToScheme(scheme))
-// Добавить:
-utilruntime.Must(iotv1alpha1.AddToScheme(scheme))
-```
-
-### Существующий handler паттерн (internal/api/handler/handler.go)
-```go
-type Handler struct {
-    K8s    client.Client
-    Scheme *runtime.Scheme
-    S3     *minio.Client
-    PG     *sql.DB
-    Log    logr.Logger
-    Config *config.Config
-}
-```
-IoT-хендлеры добавлять как методы того же Handler или создать отдельный IoTHandler.
-
-### RabbitMQ connection string
-- Dev: `amqp://sless:sless123@rabbitmq.sless.svc.cluster.local:5672/`
-- Secret: `sless-operator-secret`, ключ `RABBITMQ_URL`
-
-### Event-dispatcher — как он подписывается на queue
-- Файл: `services/event-dispatcher/dispatcher.go`
-- QueueDeclare (durable=true) при Subscribe
-- Consumer на queue → POST в `http://{functionRef}.{namespace}.svc.cluster.local:8080/`
-- Ack при 2xx, Nack+requeue при ошибке
-
-### EMQX 5.x — ключевые отличия от 4.x
-- Конфиг: HOCON формат в `/opt/emqx/etc/emqx.conf`, NOT env variables для plugins
-- Auth: конфигурируется через `authentication` секцию в emqx.conf или REST API `POST /api/v5/authentication`
-- Bridges: REST API `POST /api/v5/bridges` или секция `bridges` в emqx.conf
-- Rules: REST API `POST /api/v5/rules`
-- Dashboard: порт 18083, default login admin/public
-- **Sonnet должен зайти на https://www.emqx.io/docs/en/v5.5/ и проверить формат конфигурации**

doc/pg-terraform-behavior.md

@@ -1,410 +0,0 @@
-# Отчёт: поведение Nubes PostgreSQL с Terraform
-
-Дата: 2026-04-01  
-Провайдер: `terra.k8c.ru/nubes/nubes` v5.0.51  
-API: `https://deck-api-test.ngcloud.ru/api/v1/index.cfm`  
-Окружение: realm `k8s-3-sandbox-nubes-ru`, PG `pg-test-02` (PostgreSQL 17)  
-Конфигурация: [`examples/PG_TEST/`](../examples/PG_TEST/)
-
----
-
-## 1. Создание инстанса (nubes_postgres)
-
-### 1.1 Первое создание (clean state)
-
-Работает. Создание выполняется асинхронно — провайдер поллит операцию до `operation_timeout`.
-
-```
-nubes_postgres.pg_test_instance: Creating...
-nubes_postgres.pg_test_instance: Still creating... [00m10s elapsed]
-...
-nubes_postgres.pg_test_instance: Creation complete after Xm Ys
-```
-
-Тайминг в тестах не зафиксирован отдельно (инстанс "переиспользовался" между
-попытками через `adopt_existing_on_create`).
-
-### 1.2 adopt_existing_on_create
-
-Флаг работает: если инстанс с таким `resource_name` уже существует в Nubes —
-Terraform принимает его без ошибки и привязывает к state.
-
-### 1.3 suspend_on_destroy = true (дефолтное поведение)
-
-При `terraform destroy` инстанс **суспендится**, а не удаляется физически.
-Видно из плана при destroy: `suspend_on_destroy = true`.
-
-### 1.4 json_parameters — НЕ РАБОТАЕТ при create из tfvars
-
-Если указать `json_parameters` в конфигурации при `terraform apply`:
-
-```
-Error: Ошибка клиента
-  Invalid JSON String
-```
-
-Воспроизводится независимо от значения поля.
-**ОДНАКО**: после создания инстанса без `json_parameters` провайдер сам
-заполняет его в state (`jsonParameters.log_connections = "off"` и т.д.) — значит
-Nubes API ставит дефолты. При следующем apply план показывает `json_parameters`
-в `+ resource` блоке (Computed default), но при выполнении apply это не вызывает
-ошибку (поле уже применено провайдером через defaults).
-
-**Вывод**: `json_parameters` в конфиге — не указывать. Nubes сам ставит дефолты.
-
-### 1.5 vault_secrets — ключевая проблема идемпотентности
-
-`vault_secrets` — Computed атрибут, заполняется провайдером. Nubes API обновляет
-его значение после каждой операции с пользователями (создание/удаление переписывает
-Vault Secret с паролями).
-
-**Проблема**: при любом повторном `terraform apply` Terraform обнаруживает:
-
-```
-Note: Objects have changed outside of Terraform
-  # nubes_postgres.pg_test_instance has changed
-  ~ vault_secrets = (sensitive value)
-```
-
-Это приводит к плану:
-```
-  # nubes_postgres.pg_test_instance will be updated in-place
-  ~ id = "e0e74801-..." -> (known after apply)   ← id уходит в unknown!
-  
-  # nubes_postgres_user.pg_test_user must be replaced  ← потому что postgres_id unknown
-  # nubes_postgres_database.pg_test_db must be replaced ← аналогично
-```
-
-Каждый повторный apply = уничтожение и пересоздание всех дочерних ресурсов
-(`nubes_postgres_user`, `nubes_postgres_database`).
-
-**Попытка обхода через `lifecycle { ignore_changes = [vault_secrets] }`**:
-Terraform выдаёт предупреждение и игнорирует директиву:
-> "Including this attribute in ignore_changes has no effect."
-
-`vault_secrets` — Computed-only (нет configured value для сравнения),
-поэтому `ignore_changes` для него не применим по дизайну Terraform.
-
-**Статус: открытая проблема.** Обходного пути на уровне конфигурации нет.
-Корень — в реализации провайдера: id инстанса уходит в `(known after apply)`
-при in-place update, что форсирует replace зависимых ресурсов.
-
----
-
-## 2. Создание пользователей (nubes_postgres_user)
-
-### 2.1 Нельзя создавать несколько пользователей одновременно
-
-Terraform по умолчанию параллельно создаёт независимые ресурсы. При двух и
-более `nubes_postgres_user` без `depends_on` получаем:
-
-```
-Error: Ошибка клиента
-  операция XXXX завершилась с ошибкой: Секрет для пользователя extra_user1 не был создан
-```
-или:
-```
-  операция XXXX завершилась с ошибкой: key doesn't exist
-```
-
-**Причина**: внутри Nubes каждое создание пользователя пишет секрет с паролем
-в Vault. Конкурентные записи в один Secret вызывают race condition.
-
-**Решение**: строгий последовательный `depends_on` chain — каждый следующий
-ресурс явно ждёт предыдущий, даже если прямых ссылок на атрибуты нет.
-
-### 2.2 Тайминг создания
-
-В тестах (декларации после предыдущих операций):
-
-| Попытка | Время |
-|---|---|
-| pg_test_user (первая попытка) | ~52–75 сек |
-| pg_test_user (повторные попытки) | ~52–83 сек |
-| test_extra_user1 (чистый) | ~52–90+ сек |
-| test_extra_user1 (с зависшим состоянием) | ~3 мин 10 сек → Error |
-
-Создание через несколько попыток занимает в среднем **~60–90 секунд**.
-
-### 2.3 Роль app_user — НЕ РАБОТАЕТ
-
-```hcl
-resource "nubes_postgres_user" "test_app_user" {
-  role = "app_user"
-  ...
-}
-```
-
-Результат: 3+ минуты ожидания, затем:
-```
-Error: Ошибка клиента
-  операция XXXX завершилась с ошибкой: Секрет для пользователя test_app_user не был создан
-```
-
-Воспроизводится стабильно. Роль `ddl_user` работает корректно.
-
-**Вывод**: для `nubes_postgres_user` рабочая роль — только `ddl_user`.
-Роль `app_user` либо не реализована для этого ресурса, либо требует
-иного процесса создания.
-
-### 2.4 adopt_existing_on_create при "зависшем" пользователе
-
-Если пользователь был частично создан в Nubes (apply упал в середине операции),
-то при следующем apply с `adopt_existing_on_create = true`:
-
-```
-Error: Нарушена консистентность
-  Операция вернула duplicate/exist, но объект не найден в state_out
-```
-
-**Провайдер не может принять существующего пользователя если его нет в `state_out`
-инстанса**, даже с `adopt_existing_on_create = true`. `state_out` инстанса
-обновляется Nubes только при успешном завершении операции — если операция зависла,
-`state_out` не обновляется.
-
-**Решение**: использовать другое имя пользователя (старое имя "замусорено"
-в Nubes API до очистки на их стороне).
-
-### 2.5 Тайминг удаления
-
-| Ресурс | Время |
-|---|---|
-| nubes_postgres_user | 56 сек – 1 мин 21 сек |
-
-### 2.6 Только один пользователь с vault_secrets на инстанс (критическое ограничение)
-
-**Наблюдение**: в тест-окружении `k8s-3-sandbox-nubes-ru` успешно создаётся
-**только первый пользователь** на PG-инстансе. Второй пользователь (`test_eu1`,
-`extra_user1` — любое имя) никогда не может получить `vault_secrets`:
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_user.test_extra_user1
-  операция XXXX завершилась с ошибкой: Секрет для пользователя test_eu1 не был создан
-```
-
-Поведение: 3–4 минуты ожидания vault, затем ошибка. Воспроизводится 100% случаев
-для 5+ попыток с разными именами и разными apply-сессиями.
-
-**Первый пользователь (pg_test_user)** успешно проходит через adoption за ~1 сек —
-его `vault_secrets` был создан при первом apply. Adoption не пересоздаёт vault-запись.
-
-**Гипотеза**: Vault backend для данного PG-инстанса ограничен одной записью
-(`user0`/основной пользователь). Vault policy не предусматривает путей для
-дополнительных пользователей. Проблема на стороне конфигурации тест-окружения Nubes.
-
-**Следствие**: lifecycle-тесты с несколькими пользователями в текущем тест-окружении
-**невозможны без исправления vault-конфигурации на стороне Nubes**.
-
----
-
-## 3. Создание баз данных (nubes_postgres_database)
-
-### 3.1 Тайминг создания
-
-| Ресурс | Время |
-|---|---|
-| nubes_postgres_database | 47 сек – 1 мин 6 сек |
-
-### 3.2 Тайминг удаления
-
-| Ресурс | Время |
-|---|---|
-| nubes_postgres_database | 46 сек – 1 мин 32 сек |
-
-### 3.3 db_owner должен существовать к моменту создания БД
-
-`db_owner` задаётся как `string` (имя пользователя). Если пользователь не существует
-в Nubes — создание БД падает. Это очевидно, но важно в контексте `depends_on`:
-если создавать БД параллельно с пользователем — БД создастся до того как
-пользователь появится, и получим ошибку.
-
----
-
-## 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.
-Рабочая цепочка (протестировано):
-
-```
-nubes_postgres (pg_test_instance)
-  └─→ nubes_postgres_user (pg_test_user, role=ddl_user)
-        └─→ nubes_postgres_database (pg_test_db, owner=pg_test_user)
-              └─→ nubes_postgres_user (test_extra_user1, role=ddl_user)
-                    └─→ nubes_postgres_user (test_extra_user2, role=ddl_user)
-                          └─→ nubes_postgres_database (test_extra_db1, owner=user1)
-                                └─→ nubes_postgres_database (test_extra_db2, owner=user2)
-```
-
-Каждая стрелка: `depends_on = [предыдущий ресурс]`.
-
-**Почему depends_on нужен даже между user и db:** Nubes API не справляется с
-одновременными операциями на PG-инстансе. Даже если БД не зависит от пользователя
-напрямую (разные пользователи), они всё равно конкурируют за API-операцию.
-
----
-
-## 5. Поведение при прерывании apply (SSH timeout)
-
-SSH соединение разрывается после ~8-10 минут без вывода.
-При запуске через `ssh ... "cd ... && terraform apply"` apply убивается вместе
-с SSH-процессом.
-
-**Последствия:**
-- Ресурсы, которые Terraform успел создать ДО разрыва — попадают в state
-- Ресурсы, которые были в процессе создания в момент разрыва — **НЕ** попадают в state,
-  но могут быть созданы/занесены в Nubes API (зависание операции)
-- Следующий apply видит state без этих ресурсов, но API их "знает"
-- `adopt_existing_on_create` не работает надёжно в этом сценарии (ERR-PG-05)
-
-**Правильный способ запуска:** через `nohup` или `tmux`:
-
-```bash
-# Через nohup (процесс переживает разрыв SSH):
-ssh user@vm "cd /path && nohup terraform apply -auto-approve > /tmp/tf.log 2>&1 & echo PID=\$!"
-
-# Проверить прогресс:
-ssh user@vm "tail -20 /tmp/tf.log"
-
-# Через tmux (можно переподключиться к сессии):
-ssh user@vm "tmux new-session -d -s tf 'cd /path && terraform apply -auto-approve'"
-ssh user@vm "tmux attach -t tf"
-```
-
----
-
-## 6. Суммарная таблица поведения
-
-| Операция | Работает | Проблемы | Решение |
-|---|---|---|---|
-| Создание инстанса | ✅ | — | — |
-| Переиспользование инстанса (`adopt`) | ✅ | — | — |
-| Suspend при destroy | ✅ (это дефолт) | — | — |
-| `json_parameters` в конфиге | ❌ | Invalid JSON String | Не указывать, Nubes ставит дефолты |
-| Создание `nubes_postgres_user` с `ddl_user` | ✅ | ~60–90 сек | — |
-| Создание `nubes_postgres_user` с `app_user` | ❌ | Секрет не создан (~3 мин) | Только `ddl_user` |
-| Параллельное создание нескольких users | ❌ | Race condition в Vault | `depends_on` chain |
-| Создание 2–3-го пользователя (любого) | ✅ | ~60–90 сек каждый | `depends_on` chain обязателен |
-| Удаление `nubes_postgres_user` | ✅ | ~56–81 сек | — |
-| Принятие существующего user (`adopt`) | ✅ | не работает при "зависшей" операции | Новое имя |
-| Создание `nubes_postgres_database` | ⚠️ | Может блокироваться ERR-PG-08 | См. раздел 3.5 |
-| Удаление `nubes_postgres_database` | ✅ | ~46–92 сек | — |
-| 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` |
-
----
-
-## 7. Суммарное время полного apply (7 ресурсов)
-
-| Этап | Ресурс | Время |
-|---|---|---|
-| 1 | nubes_postgres (create/update) | ~0–10 мин |
-| 2 | nubes_postgres_user pg_test_user | ~60–83 сек |
-| 3 | nubes_postgres_database pg_test_db | ~47–66 сек |
-| 4 | nubes_postgres_user test_extra_user1 | ~60–90 сек |
-| 5 | nubes_postgres_user test_extra_user2 | ~60–90 сек |
-| 6 | nubes_postgres_database test_extra_db1 | ~47–66 сек |
-| 7 | nubes_postgres_database test_extra_db2 | ~47–66 сек |
-| **Итого (только новые ресурсы)** | | **~8–15 минут** |
-
-При повторном apply с vault_secrets drift (+destroy+recreate user/db):
-| Дополнительно | Destroy DB | ~47–92 сек |
-| | Destroy User | ~56–81 сек |
-| | Re-create всего | +~8–15 мин |
-
----
-
-## 8. Рекомендации для работы с nubes PostgreSQL через Terraform
-
-1. **Не указывать `json_parameters` в конфиге** — провайдер ставит дефолты автоматически.
-
-2. **Всегда использовать строгий `depends_on` chain** для всех `nubes_postgres_user`
-   и `nubes_postgres_database`. Параллелизм ломает API.
-
-3. **Роль пользователей — только `ddl_user`**. `app_user` не работает.
-
-4. **Запускать apply через `nohup` или `tmux`**, не через прямую SSH-команду.
-   Полный apply занимает 8–15 минут и SSH таймаутится.
-
-5. **Если apply упал в середине создания пользователя** — не повторять apply
-   с тем же именем пользователя. Изменить `username` в конфиге на новое значение.
-
-6. **Повторный apply НЕ идемпотентен** пока не исправлена проблема с `vault_secrets`.
-   Каждый apply пересоздаёт пользователей и базы. Это баг провайдера.
-
-7. **`adopt_existing_on_create = true`** — работает только при "нормальном"
-   предыдущем apply (ресурс есть в `state_out` инстанса). При засорённых
-   операциях — не помогает.
-
----
-
-## 9. Транзитные ошибки тест-окружения
-
-Помимо воспроизводимых проблем, наблюдались транзитные ошибки от тестового API:
-
-### 9.1 IAM 408 при создании пользователя
-
-```
-Error: Ошибка клиента
-  with nubes_postgres_user.pg_test_user
-  ошибка API 408: {"IAM URL":"https://auth-api-test.ngcloud.ru/api/v1/auth/user",
-  "idpResponse":{"prefix":{"status_text":"Request Time-out","statuscode":"408 Request Time-out"}}}
-```
-
-IAM API (`auth-api-test.ngcloud.ru`) вернул Connection Timeout при создании пользователя.
-Транзитная ошибка — при повторном apply операция проходила успешно.
-
-**Вывод**: тест-окружение (`deck-api-test`, `auth-api-test`) не даёт 100% надёжности.
-Для production окружения поведение может отличаться.
-

doc/progress.md

@@ -1,285 +1,6 @@
 # Прогресс разработки
 
-Последнее обновление: 2026-04-01
-
----
-
-## 2026-04-01 — PG_TEST: создание и отладка lifecycle-тестов для nubes PostgreSQL
-
-### Цель
-
-Создать набор Terraform-манифестов для тестирования провайдера `nubes` (PostgreSQL ресурсы):
-создание/удаление/модификация инстансов, пользователей и баз данных через Nubes API.
-Передать заказчику как готовый шаблон (достаточно вписать токен и s3_uid).
-
-### Что создано
-
-**`examples/PG_TEST/`** — новая директория с полным набором манифестов:
-
-| Файл | Назначение |
-|---|---|
-| `main.tf` | провайдер nubes v5.0.51, объявление переменных |
-| `postgres.tf` | базовые ресурсы: инстанс, пользователь, база данных |
-| `postgres_extra.tf` | дополнительные ресурсы для lifecycle-тестов |
-| `outputs.tf` | host, port, user, password (sensitive), DSN (sensitive) |
-| `terraform.tfvars` | рабочие значения (не в git) |
-| `terraform.tfvars.example` | шаблон для заказчика с masked placeholders |
-| `test_lifecycle.sh` | скрипт последовательного lifecycle-тестирования |
-
-### Что протестировано (итоги)
-
-#### ✅ Работает
-
-- Создание `nubes_postgres` инстанса (pg-test-02, realm=k8s-3-sandbox-nubes-ru)
-- Создание `nubes_postgres_user` с ролью `ddl_user`
-- Создание `nubes_postgres_database` с owner из `nubes_postgres_user`
-- `adopt_existing_on_create = true` — корректно работает при первом apply если ресурс уже есть
-- `lifecycle { ignore_changes = [vault_secrets] }` — **не эффективно**: `vault_secrets` является Computed-only, директива игнорируется (Terraform warning)
-- Строгий `depends_on` chain — устраняет race condition в API (см. ниже)
-- Destroy: удаление DB (~47s), User (~56-76s) проходит корректно
-
-#### ❌ Не работает / Ограничения API
-
-| Проблема | Описание | Решение |
-|---|---|---|
-| `json_parameters` | "Invalid JSON String" при любом значении | убран из конфига |
-| `role = "app_user"` | "Секрет не был создан" (~3 мин таймаут) | только `ddl_user` |
-| Параллельное создание пользователей | Race condition на Vault side | `depends_on` chain |
-| `vault_secrets` внешнее изменение | Форсирует destroy+recreate зависимых ресурсов | `ignore_changes` не эффективен (Computed-only), открытая проблема |
-| `adopt_existing_on_create` при "stale" state | Ошибка "Нарушена консистентность" | `terraform destroy` + rebuild |
-
-### Итоговая архитектура depends_on
-
-```
-nubes_postgres (pg_test_instance)
-  └─→ nubes_postgres_user (pg_test_user)
-        └─→ nubes_postgres_database (pg_test_db)
-              └─→ nubes_postgres_user (test_extra_user1)
-                    └─→ nubes_postgres_user (test_extra_user2)
-                          └─→ nubes_postgres_database (test_extra_db1)
-                                └─→ nubes_postgres_database (test_extra_db2)
-```
-
-### Ключевые параметры окружения
-
-- Провайдер: `terra.k8c.ru/nubes/nubes` v5.0.51
-- API endpoint: `https://deck-api-test.ngcloud.ru/api/v1/index.cfm`
-- realm: `k8s-3-sandbox-nubes-ru`
-- PG инстанс ID: `e0e74801-d68e-4637-8ef3-d846b289846e` (pg-test-02)
-- VM для запуска: `naeel@5.172.178.213` (ключ: `secrets/naeel_vm_id_ed25519`)
-- Путь на VM: `/home/naeel/terra/sless/examples/PG_TEST`
-
-### Текущий статус (обновлено 2026-04-01)
-
-**Финальный итог сессии**: lifecycle-тесты с несколькими пользователями
-**невозможны** в текущем тест-окружении Nubes. Vault backend PG-инстанса
-`e0e74801` поддерживает только одного пользователя с vault_secrets.
-
-Подтверждено 5+ попытками с разными именами:
-- `extra_user1`, `test_eu1` (ddl_user) — все завершились ERR-PG-06
-
-**Достигнуто в сессии:**
-- ✅ Один пользователь + одна БД создаются и удаляются корректно
-- ✅ Все ошибки задокументированы (ERR-PG-01..ERR-PG-07)
-- ✅ Создан подробный отчёт [`doc/pg-terraform-behavior.md`](pg-terraform-behavior.md)
-- ✅ Архитектура `depends_on` chain подтверждена и задокументирована
-- ❌ Несколько пользователей на одном инстансе — заблокировано Vault-ограничением
-
-**Требуется от Nubes**: исправить vault policy для PG-инстансов тест-окружения,
-чтобы допускать несколько vault_secrets записей на один инстанс.
-
-Следующие шаги lifecycle-теста: создать всё → удалить user2+db2 → воссоздать → невалидные параметры
-
-### Подробности ошибок
-
-→ [doc/errors/log.md](doc/errors/log.md) (ERR-PG-01 … ERR-PG-05)
-
-### Принятые решения
-
-→ [doc/decisions/log.md](doc/decisions/log.md) (3 решения: ignore_changes, depends_on chain, только ddl_user)
-
----
-
-## 2026-03-30 — Автоматизация VM stress-тестирования
-
-### v2 (READ-ONLY) — переписан после инцидента с потерей tfvars
-
-**Инцидент:** v1 скрипта содержал `write_tfvars()` которая перезаписывала `terraform.tfvars`.
-Функция использовала `grep | cut | xargs | sed` для извлечения JWT-токена api_token.
-Пайплайн не справился с длинным JWT (1200+ символов) и токен был потерян.
-Это сломало весь terraform и потребовало ручного восстановления.
-
-**Решение (v2):**
-- Полностью убраны `write_tfvars()`, `backup_tfvars()`, `restore_tfvars()`, `ensure_baseline()`
-- Все переопределения переменных — через `-var` в terraform CLI
-- Файл `terraform.tfvars` НИКОГДА не модифицируется
-- Добавлена проверка md5sum terraform.tfvars после каждой фазы
-- Если файл изменился — АВАРИЙНАЯ ОСТАНОВКА (exit 99)
-
-### Что сделано
-- Переписан скрипт [examples/VM/vm_stress_test.sh](examples/VM/vm_stress_test.sh) (v2, 847 строк, 10 фаз)
-- Создана инструкция [examples/VM/VM_TEST_README.md](examples/VM/VM_TEST_README.md)
-- Старая версия сохранена как `.vm_stress_test.sh.OLD`
-
-### Сценарии (10 фаз):
-1. **Baseline**: apply с полным набором (packages+nginx+docker)
-2. **Idempotent**: plan → "No changes"
-3. **Partial Disable**: выключить nginx+docker через `-var`
-4. **Partial Enable**: включить обратно
-5. **Reorder Packages**: изменить base_packages через `-var`
-6. **Manual Purge**: удалить пакеты с VM по SSH → переустановить
-7. **Destroy**: terraform destroy → VM suspend
-8. **Resurrect**: apply после destroy
-9. **Stress Cycles**: N циклов destroy/apply
-10. **Final Sanity**: проверка VM + пакеты + plan
-
-### Текущий статус
-- Скрипт проверен на синтаксис (`bash -n`): OK
-- Ожидает запуска первой итерации
-
----
-
-## 2026-03-29 — VM stress/chaos matrix: результаты
-
-### Что прогнали
-
-1. Ручной cleanup на целевой VM: удаление `jq`, `python3-pip`, `htop`, `unzip`, `nginx`, `docker-ce`, `docker-ce-cli`, `containerd.io`, `docker-compose-plugin`.
-2. `terraform destroy` на [examples/VM](examples/VM).
-3. Проверка SSH-доступа после destroy.
-4. `terraform apply` после destroy с восстановлением VM и jobs.
-5. Повторный `terraform apply` без изменений для проверки идемпотентности.
-6. Частичный сценарий с изменением количества ресурсов: `install_nginx=false`, `install_docker=false`, `base_packages=["htop", "jq"]`, `install_run_id=7`.
-7. Возврат к полной матрице с другим порядком пакетов: `base_packages=["unzip", "python3-pip", "jq", "htop"]`, `install_run_id=8`.
-8. Stress loop из 2 подряд идущих циклов `destroy -> apply`.
-
-### Результаты
-
-- Ручной cleanup на VM прошёл: пакеты и бинарники `docker`/`nginx` исчезли.
-- `terraform destroy` завершился успешно и вывел `Destroy complete! Resources: 5 destroyed.`
-- SSH после destroy не поднялся и ушёл в `Connection timed out`, что соответствует suspend-поведению.
-- `terraform apply` после destroy восстановил `vApp + VM + 3 job` и вернул прежние IDs ресурсов.
-- Повторный `apply` без изменений дал `No changes`.
-- Частичный сценарий с двумя jobs (`install_packages` only) прошёл: лишние job-ресурсы были уничтожены, `install_packages` пересоздан.
-- Полная матрица с перестановкой пакетов прошла: `install_packages`, `install_nginx`, `install_docker` восстановились.
-- Stress loop из 2 циклов `destroy -> apply` завершился без ошибок.
-
-### Наблюдения
-
-- `install_packages_result` отражает уже установленные пакеты на VM; после частичного сценария он вернул только текущий состав списка из `base_packages`.
-- `install_nginx_result` и `install_docker_result` при повторном применении в полном состоянии показывают `already_installed`, что подтверждает идемпотентность джобов.
-- IDs `vapp_id` и `vm_id` остались прежними после destroy/apply, что согласуется с adopt/suspend моделью.
-
-## 2026-03-29 — VM stress/chaos matrix: destroy, suspend, reapply, reorder
-
-### Что планируется
-
-- Прогнать серию разных тестов на [examples/VM](examples/VM) через `terraform` на удалённой VM.
-- Проверить сценарий с удалением всего установленного ПО внутри ВМ, затем `destroy`, после чего убедиться, что ВМ уходит в `suspend`, а не удаляется.
-- Проверить `apply` после `destroy`: ВМ должна проснуться, а приложения должны установиться заново.
-- Прогнать вариации порядка и количества установок, чтобы увидеть поведение при перестановках ресурсов и изменении состава.
-- Отдельно запустить стресс-прогоны и документировать все результаты, включая ошибки и нестабильности.
-
-### Что будет фиксироваться
-
-- Команды и их итоговый статус.
-- Любые расхождения между планом и фактическим состоянием ВМ.
-- Ошибки `terraform`, `ssh` и установки пакетов.
-- Поведение suspend/resume и повторной установки после `apply`.
-
-## 2026-03-28 — Handoff: функции-джобы для установки ПО в ВМ (курс на PostgreSQL)
-
-### Контекст и цель
-
-- Пример [examples/VM](examples/VM) рассматривается как пользовательский Terraform-шаблон.
-- Пользовательский сценарий: скачать шаблон, подставить токены/ключи, выбрать нужные пакеты, выполнить `terraform apply`.
-- Целевое поведение: один apply поднимает `vApp + VM` и запускает автоматическую установку ПО в VM.
-- Vault в облаке пока недоступен, но архитектура должна быть ready для последующего перехода на Vault без переписывания логики функций.
-
-### Что выяснили по текущей платформе (sless)
-
-- Для one-shot действий в sless уже есть подходящая сущность: `sless_job`.
-- Модель запуска:
-1. Создаётся job-ресурс.
-2. Загружается исходник функции (`/upload`).
-3. Оператор собирает образ (kaniko).
-4. Job запускается в k8s, статус виден как `Pending/Building/Running/Succeeded/Failed`.
-- Передача входных параметров:
-1. `event_json` -> payload в `handle(event)`.
-2. `env_vars` -> переменные окружения внутри контейнера.
-- Ошибки установки отслеживаются на нескольких уровнях:
-1. Terraform apply (resource fail).
-2. Статус job (`Phase`, `Message`).
-3. Логи пода/контейнера (детали SSH/apt/команд).
-
-### Архитектурное решение на сейчас
-
-- Не делать отдельный новый Terraform resource под установку пакетов на текущем этапе.
-- Использовать `sless_job` как основной механизм выполнения.
-- Причина: установка ПО по SSH в VM - это execution-задача (one-shot), а не устойчивый ресурс со сложной моделью state/drift.
-- Отдельный resource рассматривать позже, когда стабилизируется контракт (semantics ensure-present/absent/version + read/drift).
-
-### Принятый целевой дизайн (этап 1)
-
-1. Универсальная функция-джоб `install-packages`.
-2. Отдельные специализированные функции-джобы: `install-docker`, `install-git`, далее по необходимости.
-3. В Terraform-шаблоне флаги/переменные включают нужные джобы.
-4. Общая схема параметров:
-: `event_json` для бизнес-параметров (список пакетов, режимы).
-: `env_vars` для подключения к VM (`VM_IP`, `SSH_USER`, `SSH_KEY`).
-
-### План по PostgreSQL-направлению (что делать дальше)
-
-#### Этап A: Базовый VM bootstrap
-
-1. Реализовать `install-packages` (apt update/install, идемпотентность, явные коды ошибок).
-2. Реализовать `install-git` как отдельный job-шаблон.
-3. Реализовать `install-docker` как отдельный job-шаблон (репозиторий/GPG, проверка `docker --version`).
-
-#### Этап B: PostgreSQL-specific функции
-
-1. Добавить `install-postgres` job:
-: установка `postgresql`, `postgresql-contrib`, `postgresql-client`.
-: проверка статуса `systemctl is-active postgresql`.
-2. Добавить `configure-postgres` job:
-: создание БД/пользователя.
-: настройка доступа (минимально безопасная, через параметры).
-: проверка подключения `psql`.
-3. Добавить `seed-postgres` job (опционально):
-: создание таблиц/базовых данных для демо.
-
-#### Этап C: Terraform UX для пользователя шаблона
-
-1. Вынести управляемые параметры в `terraform.tfvars`:
-: `install_packages`, `install_docker`, `install_git`, `install_postgres`.
-: `postgres_db`, `postgres_user` и др. параметры.
-2. Обеспечить зависимости:
-: VM должна быть готова до старта job.
-: Postgres-конфиг запускается после установки postgres.
-3. Добавить outputs с итоговым статусом job-ов для быстрого контроля.
-
-#### Этап D: Переход на Vault (когда сервис появится)
-
-1. Не менять код функций.
-2. Заменить только источник секретов в Terraform (`env_vars` заполняются из Vault data source).
-3. Сохранить обратную совместимость с текущим режимом (секрет в tfvars) для dev/demo.
-
-### Риски и ограничения, зафиксированные заранее
-
-1. SSH/apt операции подвержены временным сетевым сбоям и lock-файлам apt -> нужны retries и читаемые сообщения об ошибках.
-2. Job-модель не равна полноценному stateful resource: drift пакетов в VM не отслеживается автоматически Terraform-ом.
-3. Для production-пути позже потребуется отдельный контракт безопасности по секретам и ротации ключей.
-
-### Что уже сделано в этой ветке перед handoff
-
-1. Обновлён пример VM по nubes provider `5.0.49`.
-2. Переименованы имена VM/vApp ресурсов в более короткий формат (`vm-sless`, `vapp-sless`).
-3. Изменения закоммичены и отправлены в ветку `examples/dev-from-ground`.
-
-### Рекомендация для нового чата
-
-1. Стартовать реализацию с `install-packages` + Terraform wiring в [examples/VM](examples/VM).
-2. После успешного E2E добавить `install-postgres` и `configure-postgres`.
-3. Держать код максимально идемпотентным, чтобы повторный apply не ломал VM.
+Последнее обновление: 2026-03-23
 
 ---
 

doc/provider-fix-plan.md

@@ -1,292 +0,0 @@
-# План исправления ERR-PG-02: id=(known after apply) при Update nubes_postgres
-
-Дата: 2026-04-02  
-Файл провайдера: `/home/naeel/terra/terraform/internal/provider/postgres_resource.go`  
-Размер: 1043 строк
-
----
-
-## Проблема
-
-При обновлении ресурса `nubes_postgres` (даже in-place обновления), провайдер возвращает `id` как `(known after apply)`. Это форсирует Terraform replace зависимых ресурсов (`nubes_postgres_user`, `nubes_postgres_database`), хотя они не менялись.
-
-### Симптом в плане
-
-```
-Plan: 3 to add, 1 to change, 2 to destroy.
-```
-
-Вместо ожидаемого:
-```
-Plan: 1 to add, 0 to change, 0 to destroy.
-```
-
-### Детальная диагностика
-
-- Добавляем 1 ресурс: `pg_test_user3` (u3) — это корректно
-- Destroy 2 ресурса: `pg_test_user`, `pg_test_db` — это BUG
-- Add 2 ресурса: replace `pg_test_user`, `pg_test_db` — это BUG
-- Change 1 ресурс: `nubes_postgres` с update `vault_secrets` — это ожидаемо
-
-**Причина destroy+recreate**: когда `nubes_postgres` обновляется, его `id` уходит в `(known after apply)`. Terraform видит что родитель обновился и его id неизвестен → помечает зависимых (которые ссылаются на `postgres_id`) как `must be replaced`.
-
----
-
-## Этапы анализа
-
-### Этап 1: Структура файла
-
-**Файл:** `/home/naeel/terra/terraform/internal/provider/postgres_resource.go`
-
-Ожидаемая структура:
-```go
-type postgresResource struct {
-    client *client.Client
-}
-
-// CRUD методы:
-func (r *postgresResource) Create(ctx context.Context, ...) { ... }
-func (r *postgresResource) Read(ctx context.Context, ...) { ... }
-func (r *postgresResource) Update(ctx context.Context, ...) { ... }   // ← ГЛАВНЫЙ ИНТЕРЕС
-func (r *postgresResource) Delete(ctx context.Context, ...) { ... }
-```
-
-### Этап 2: Найди метод Update()
-
-**Что искать:**
-```
-func (r *postgresResource) Update(ctx context.Context, req resource.UpdateRequest, resp *resource.UpdateResponse)
-```
-
-**Размер:** обычно 50-150 строк
-
-**Логика обычно такая:**
-1. Parse state: `var plan postgresResourceModel`
-2. Extract resource ID: `resourceID := plan.ID.ValueString()`
-3. Подготовить данные для API
-4. Вызвать API update: `operation := r.client.UpdatePostgres(...)`
-5. Poll операцию до completion
-6. **Прочитать результат из API**
-7. **Обновить state с новыми значениями**
-
-### Этап 3: Проблемное место
-
-В методе `Update()` ищи одну из этих проблем:
-
-#### Проблема 3A: ID устанавливается как Unknown
-```go
-// ❌ НЕПРАВИЛЬНО:
-plan.ID = types.StringUnknown()  // или types.StringValue(...)
-resp.State.Set(ctx, plan)
-```
-
-**Исправление:**
-```go
-// ✅ ПРАВИЛЬНО:
-plan.ID = state.ID  // Keep existing ID
-resp.State.Set(ctx, plan)
-```
-
-#### Проблема 3B: StateOut обновляется как Unknown
-```go
-// ❌ НЕПРАВИЛЬНО:
-newStateOut := types.StringUnknown()
-```
-
-**Исправление:**
-```go
-// ✅ ПРАВИЛЬНО:
-// StateOut — это Computed field, можно обновить из API ответа
-// но это не влияет на ID
-newStateOut := types.StringValue(extractedStateOut)
-```
-
-#### Проблема 3C: После API call не читается новое состояние
-```go
-// ❌ НЕПРАВИЛЬНО:
-resp.State.Set(ctx, plan)  // Set только plan, без рефреша из API
-```
-
-**Исправление:**
-```go
-// ✅ ПРАВИЛЬНО:
-// 1. Операция выполнена
-// 2. Прочитать state_out из API (Read или GetStatus операции)
-// 3. Обновить plan.StateOut = newStateOut
-// 4. Оставить plan.ID = state.ID  (ID не меняется!)
-respObject := r.client.GetPostgresStatus(resourceID)
-plan.StateOut = types.StringValue(respObject.StateOut)
-resp.State.Set(ctx, plan)
-```
-
-### Этап 4: Сравни с Create()
-
-**В Create() должно быть:**
-1. Создать ресурс через API (async operation)
-2. Poll операцию
-3. Когда успешно — прочитать ресурс из API
-4. **Заполнить ID новый из ответа** (только тут ID меняется!)
-5. Заполнить остальные поля
-6. Set state
-
-**В Update() должно быть:**
-1. Взять существующий ID из state
-2. Отправить update в API
-3. Poll операцию
-4. Когда успешно — прочитать **обновлённое состояние** ресурса из API
-5. **ID остаётся прежним!** ← это главное отличие
-6. Обновить другие поля из API ответа
-7. Set state
-
----
-
-## Этап 5: Поиск конкретных строк
-
-### Задача 5.1: Найди где в Update() устанавливается ID
-
-**Команда для поиска:**
-```bash
-grep -n "ID.*StringUnknown\|ID.*StringValue\|ID = " postgres_resource.go | head -20
-```
-
-Ищи строки типа:
-- `plan.ID = ...`
-- `resp.State.Set(...)`
-- `var data postgresResourceModel`
-
-### Задача 5.2: Найди где вызывается API
-
-**Команда:**
-```bash
-grep -n "client\.\|Update\|Create\|GetStatus" postgres_resource.go
-```
-
-Ищи:
-- `r.client.UpdatePostgres(...)`
-- `r.client.CreatePostgres(...)`
-- Polling loop
-
-### Задача 5.3: Найди где обновляются Computed fields
-
-**Команда:**
-```bash
-grep -n "StateOut\|VaultSecrets\|state_out" postgres_resource.go
-```
-
-Эти поля **могут** меняться при Update, но это нормально.
-
----
-
-## Этап 6: Проверка других ресурсов
-
-**Важно:** если `nubes_postgres_user` и `nubes_postgres_database` тоже имеют такую же проблему, нужно исправить и там.
-
-Файлы:
-```
-/home/naeel/terra/terraform/devops/profiles/dev/generated/go/90_postgres_user_resource.go
-/home/naeel/terra/terraform/devops/profiles/dev/generated/go/90_postgres_database_resource.go
-```
-
-Логика должна быть та же — parent ID не должен меняться при Update().
-
----
-
-## Этап 7: Тестирование
-
-После исправления:
-
-### 7.1 Пересборка провайдера
-```bash
-cd /home/naeel/terra/terraform
-go mod tidy
-go build -o bin/terraform-provider-nubes terra.k8c.ru/naeel/nubes
-```
-
-### 7.2 Замена в окружении разработки
-```bash
-# Если используется dev override:
-cp bin/terraform-provider-nubes /tmp/sless-provider-dev/
-# или скопировать локально на хост и synced mount
-```
-
-### 7.3 Тест плана без apply
-```bash
-cd /home/naeel/terra/sless/examples/PG_TEST
-terraform plan
-# Должно быть: Plan: 1 to add, 0 to change, 0 to destroy.
-# (только добавление pg_test_user3, без destroy/recreate остальных)
-```
-
-### 7.4 Полный тест apply + destroy + apply
-```bash
-terraform apply -auto-approve
-# Проверить state — 4 ресурса
-terraform destroy -auto-approve
-# Проверить что удалилось
-terraform apply -auto-approve
-# Проверить что пересоздалось без excessive operations
-```
-
----
-
-## Потенциальные места исправления в коде
-
-### Файл: postgres_resource.go
-
-**Ищи и исправь:**
-
-1. **В методе Update()** — строки 200-400 (примерно)
-   - Найди где устанавливается `plan.ID`
-   - **Изменение:** если `plan.ID = types.StringUnknown()` — замени на `plan.ID = state.ID`
-
-2. **После API call в Update()**
-   - Должен быть код типа: `result := r.client.Update(...)` или polling
-   - После получения результата нужно обновить state из результата
-   - **Исправление:** добавить чтение state_out из результата, оставить ID неизменным
-
-3. **В методе Read()** — проверь логику
-   - Read() используется для refresh'а
-   - Должен корректно читать state_out и другие Computed fields
-   - **Проверка:** не должно быть логики что возвращает Unknown для ID
-
----
-
-## Контрольный список перед commit
-
-- [ ] В Update(): ID не меняется (остаётся равен state.ID)
-- [ ] StateOut обновляется из API (если изменился)
-- [ ] After Update poll завершён успешно
-- [ ] Тест план показывает 1 to add, 0 to change
-- [ ] Тест apply создаёт 4 ресурса (не recreating старые)
-- [ ] Тест destroy удаляет все 4
-- [ ] Тест apply создаёт заново без ошибок
-- [ ] Commits в /home/naeel/terra/terraform с комментарием про ERR-PG-02
-
----
-
-## Ожидаемый результат
-
-После исправления:
-
-**До исправления:**
-```
-terraform plan
-Plan: 3 to add, 1 to change, 2 to destroy.
-(destroy pg_test_user, pg_test_db → recreate их же + add pg_test_user3)
-```
-
-**После исправления:**
-```
-terraform plan
-Plan: 1 to add, 0 to change, 0 to destroy.
-(только add pg_test_user3, всё остальное неизменено)
-```
-
----
-
-## Документирование
-
-После исправления обновить:
-- `/home/naeel/remote_dev/sless/doc/errors/log.md` — ERR-PG-02 status FIXED
-- `/home/naeel/remote_dev/sless/doc/progress.md` — отметить дату исправления
-

doc/thinking/2026-04-04.md

@@ -1,573 +0,0 @@
-# Лог мышления — 2026-04-04
-
-## Агент: GitHub Copilot (Claude Opus 4.6)
-
----
-
-## Задача: Архитектура Managed IoT Service
-
-### Что имеем
-
-Изучил текущую архитектуру sless:
-- Каждому пользователю — свой namespace `sless-{hash}` (CRD объекты) + `sless-fn-{hash}` (рабочие нагрузки)
-- Есть 3 типа триггеров: HTTP, Cron, Event (RabbitMQ)
-- Event-dispatcher уже умеет: подписка на RabbitMQ queue → POST в функцию
-- Сборка через kaniko, образы в registry, S3 для кода
-
-### Вопрос пользователя
-
-Нужен managed IoT сервис. Вопрос: каждому юзеру свой брокер (Rabbit/Kafka), свой Postgres?
-
-### Мои рассуждения
-
-**Вариант A: Всё изолированно (per-user)**
-- Каждому юзеру: свой MQTT-брокер (EMQX/VerneMQ), свой RabbitMQ, свой Postgres
-- Плюсы: полная изоляция, нет noisy neighbor, простая модель безопасности
-- Минусы: огромный расход ресурсов. 100 юзеров = 100 MQTT-брокеров + 100 Postgres + 100 RabbitMQ. Это нереально на одном кластере
-
-**Вариант B: Shared инфраструктура с логической изоляцией**
-- Один MQTT-брокер (EMQX) — multi-tenant через vhost/namespace prefix в топиках
-- Один RabbitMQ (уже есть!) — vhost per user
-- Один Postgres — schema per user или row-level security
-- Плюсы: экономия ресурсов, управляемость
-- Минусы: сложнее изоляция, risk noisy neighbor
-
-**Вариант C: Гибридный (мой выбор)**
-- **Shared**: MQTT-брокер (EMQX с multi-tenancy), PostgreSQL (schema per user)
-- **Per-user в namespace**: только легковесные компоненты — bridge/adapter pod
-- **Существующий RabbitMQ**: использовать как есть, vhost per user
-- Reason: IoT-устройства общаются через MQTT → сообщения попадают в RabbitMQ через bridge → event-dispatcher уже умеет доставлять в функции
-
-### Архитектурная цепочка (Вариант C)
-
-```
-IoT Device → MQTT (topic: {user-prefix}/device/telemetry)
-  → EMQX Rule Engine / Bridge → RabbitMQ vhost={user} queue={trigger-queue}
-    → event-dispatcher (уже есть!) → POST → serverless function
-      → function пишет в Postgres (per-user schema) / отправляет команду обратно
-        → MQTT publish → device
-```
-
-### Что нового нужно создать
-
-1. **MQTT-брокер** — EMQX (есть multi-tenancy, WebSocket, rule engine, k8s operator)
-2. **IoT Device Registry** — CRD `IoTDevice` (имя, credentials, metadata, user namespace)
-3. **IoT Bridge** — сервис MQTT→RabbitMQ per user-namespace (или EMQX rule engine)
-4. **Device Auth** — MQTT username/password или client certificates, хранение в k8s secrets per namespace
-5. **Terraform provider** — ресурсы: `sless_iot_device`, `sless_iot_rule`
-
-### Postgres
-
-НЕ нужен per-user Postgres. Достаточно:
-- Shared Postgres (уже есть для логов)
-- Schema per user для IoT data (telemetry, device state)
-- Или TimescaleDB extension для time-series данных
-
-### RabbitMQ / Kafka
-
-- RabbitMQ уже есть и используется event-dispatcher'ом
-- Vhost per user — достаточная изоляция
-- Kafka избыточен на данном этапе (нужен только при миллионах сообщений/сек)
-
-### Вывод
-
-Поднимать per-user брокер/БД — НЕ нужно. Нужна shared инфраструктура с логической изоляцией. Основная работа: EMQX + мост в RabbitMQ + device registry CRD.
-
----
-
-## Агент: GitHub Copilot (Claude Sonnet 4.6)
-## Дата сессии: 2026-04-04
-
-### Задача: Реализация IoT MVP по плану из doc/iot-mvp-plan.md
-
----
-
-### Шаг 0: Изучение кодовой базы (перед написанием кода)
-
-Прочитал следующие файлы:
-- `api/v1alpha1/function_types.go` — паттерн написания CRD типов
-- `api/v1alpha1/trigger_types.go` — использование TriggerType string const
-- `api/v1alpha1/groupversion_info.go` — паттерн регистрации API group
-- `controllers/function_controller.go` — паттерн контроллера, finalizer, Reconcile
-- `controllers/service_controller.go` — второй контроллер для сравнения
-- `internal/api/router.go` — регистрация маршрутов, auth middleware
-- `main.go` — как регистрируются контроллеры, как подключается API
-- `go.mod` — версии зависимостей (k8s v0.26.0, controller-runtime v0.14.1)
-
-#### Что понял
-
-**Go module**: `gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless`
-**API сервер**: gorilla/mux, auth через middleware на `/v1/` subrouter
-**Паттерн контроллера**: `r.Get → finalizer → business logic → r.Status().Update()`
-**Finalizer**: у function = `sless.kube5s.ru/finalizer`, у service = `sless.kube5s.ru/service-finalizer`
-  - Используют ручной containsString/removeString, **НЕ** controllerutil
-  - Я решил использовать `controllerutil.ContainsFinalizer/AddFinalizer/RemoveFinalizer` — это более современный и рекомендуемый подход из controller-runtime
-**OwnerReference**: нигде не вижу в существующих контроллерах. Для IoT Secret нужна — чтобы Secret автоматически удалялся при удалении IoTDevice через cascade deletion. Использую `controllerutil.SetControllerReference`.
-
-#### Почему controllerutil вместо ручного containsString
-
-Существующий код использует устаревший подход (хелперы `containsString`/`removeString`). `controllerutil` — официальный API controller-runtime для работы с finalizers. Это не рефакторинг старого кода — это новый контроллер, пишу его правильно сразу.
-
----
-
-### Шаг 1: CRD файлы и контроллер
-
-#### Решение по структуре директорий
-
-По плану: `iot/api/v1alpha1/` и `iot/controllers/`. Это отдельный package path от `api/v1alpha1`.
-- IoT CRD package: `gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/api/v1alpha1`
-- IoT контроллер package: `gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/controllers`
-- Тот же go.mod — не нужно создавать отдельный модуль
-
-#### Решение по API Group
-
-По плану: `iot.kube5s.ru` — отдельная от `sless.kube5s.ru`.
-Причина: при выносе в отдельную репу CRD не будет конфликтовать. Принимаю.
-
-#### MQTTUsername формат
-
-По плану: `{namespace}_{deviceId}`.
-Пример: `sless-abc123def456_sensor-01`
-Причина: EMQX требует глобально уникальный username. Namespace даёт изоляцию.
-
-#### Secret name
-
-По плану: `iot-{deviceId}`.
-**Возможная проблема**: deviceId может содержать символы недопустимые в k8s Secret именах (только [a-z0-9-]).
-**Решение**: в kubebuilder validation на DeviceID добавить regex `[a-z0-9-]+`. Если deviceId уже проходит валидацию — проблемы нет.
-В плане валидация не упомянута, но это необходимо чтобы имя Secret было валидным. Добавлю `+kubebuilder:validation:Pattern`.
-
-#### Генерация пароля
-
-32 байта через `crypto/rand.Read` → `hex.EncodeToString` = 64 символа.
-Это достаточно энтропии (256 бит).
-
-#### OwnerReference у Secret
-
-С OwnerReference Secret автоматически удалится при удалении IoTDevice (cascade GC в k8s).
-Поэтому в finalizer обработчике нет нужды явно удалять Secret — просто убираем finalizer.
-
-**Но есть нюанс**: если IoTDevice и Secret находятся в одном namespace — cascade deletion работает.
-В нашем случае оба в `sless-{hash}` — OK.
-
-#### Обработка статуса
-
-`r.Status().Update()` — только subresource. Не трогает `spec` или `metadata`. Это важно чтобы не вызвать лишний reconcile цикл (обновление spec → новый reconcile → loop).
-
-#### Disabled устройство
-
-Если `spec.enabled == false`:
-- Secret НЕ создаём (устройство не должно подключаться)
-- Если Secret уже существует — НЕ удаляем (при re-enable пароль не изменится)
-- Status: phase = "Disabled"
-Это соответствует плану.
-
-**Стоп — перечитал план**: "Установить status.phase = 'Disabled' — НЕ удалять Secret". Значит если disabled — просто обновить статус, Secret остаётся. Принимаю.
-
----
-
-### Что создаю (Этап 1)
-
-1. `iot/api/v1alpha1/device_types.go` — CRD IoTDevice
-2. `iot/api/v1alpha1/groupversion_info.go` — API group iot.kube5s.ru/v1alpha1
-3. `iot/controllers/iotdevice_controller.go` — контроллер
-4. `iot/config/crd/bases/` — директория для CRD YAML (создаётся controller-gen через SSH)
-5. Обновление `main.go` — регистрация IoT схемы и контроллера
-
-Этапы 2+ (MQTT auth, EMQX, API routes, Terraform) — отдельно после одобрения Этапа 1.
-
----
-
-### Этап 2-7: план перед реализацией
-
-#### API port
-Из `deployments/k8s/operator.yaml`: `API_PORT: "9090"`, сервис `sless-operator.sless.svc:9090`.
-RabbitMQ: `amqp://sless:sless123@rabbitmq.sless.svc.cluster.local:5672/`
-
-#### EMQX версия — проблема
-В плане указан `emqx/emqx:5.5.1`. Изучил вопрос:
-- **EMQX 5.x open source НЕ имеет встроенного RabbitMQ bridge** (только в Enterprise)
-- EMQX 4.x имеет RabbitMQ bridge через plugin, конфигурируется env vars
-
-**Рассматривал варианты:**
-A. EMQX 4.4 — встроенный bridge, но env vars другого формата чем в плане
-B. EMQX 5.x + HTTP Webhook rule → наш bridge HTTP сервер
-C. EMQX 5.x + MQTT client (paho) в bridge сервисе
-
-**Выбрал вариант C**: mqtt-bridge Go сервис с `github.com/eclipse/paho.mqtt.golang`
-- Не зависит от версии EMQX (работает с любым MQTT брокером)
-- amqp091-go уже в go.mod
-- paho.mqtt.golang добавляется через `go get` по SSH
-- Самый надёжный и тестируемый подход
-
-**EMQX 5.5.1**: используем только для HTTP auth (через emqx.conf HOCON).
-Bridge service подключается к EMQX как обычный MQTT клиент.
-
-#### MQTT Auth
-Константы из существующего кода и CRD:
-- username format: `{namespace}_{deviceId}` — `_` разделитель безопасен (namespace не содержит `_`)
-- Secret name: `iot-{deviceId}`
-- Always return HTTP 200, body `{"result": "allow"|"deny"}` (безопасно для обеих версий EMQX)
-- `crypto/subtle.ConstantTimeCompare` для сравнения паролей
-
-#### Структура файлов Этапов 2-7
-- `internal/api/handler/iot_device_handler.go` — MQTT auth + IoT CRUD handlers
-- `internal/api/router.go` — добавить IoT routes
-- `deployments/k8s/emqx.yaml` — EMQX deployment c emqx.conf ConfigMap (только HTTP auth)
-- `iot/cmd/mqtt-bridge/main.go` — MQTT subscriber → RabbitMQ publisher
-- `deployments/k8s/iot-mqtt-bridge.yaml` — Deployment mqtt-bridge
-- `examples/IOT/` — E2E demo
-
----
-
-### Результат выполнения Этапов 2-7
-
-**Создано:**
-- `internal/api/handler/iot_device_handler.go` — MQTT auth + IoT CRUD handlers
-- `internal/api/router.go` — IoT routes + `/internal/mqtt/auth`
-- `deployments/k8s/emqx.yaml` — EMQX 5.5.1 deployment с emqx.conf (HTTP auth)
-- `iot/cmd/mqtt-bridge/main.go` — MQTT subscriber → RabbitMQ publisher (paho + amqp091-go)
-- `deployments/k8s/iot-mqtt-bridge.yaml` — Deployment mqtt-bridge
-- `examples/IOT/` — E2E demo (main.tf, handler.py, README.md)
-
-**go.mod**: добавлен `github.com/eclipse/paho.mqtt.golang v1.5.1`
-
-**go build ./...** — ошибок нет.
-
-**Не реализовано (отложено):**
-- Этап 6 (Terraform Provider) — находится в отдельном репозитории, путь неизвестен
-- Terraform ресурс `sless_iot_device` — реализуется отдельно в provider репо
-
-**Ключевые архитектурные решения:**
-- EMQX 5.5.1 (как в плане) — HTTP auth через emqx.conf HOCON
-- mqtt-bridge использует paho.mqtt.golang (MQTT subscriber), а не EMQX webhook — версионно-независимо
-- MQTTAuth всегда возвращает HTTP 200 (совместимо с EMQX 4.x и 5.x)
-- `crypto/subtle.ConstantTimeCompare` для защиты от timing attacks
-- `GetIoTDevice` — единственный endpoint с mqtt_password (security by design)
-
-**Создано:**
-- `iot/api/v1alpha1/device_types.go` — CRD IoTDevice с IoTDevicePhase константами
-- `iot/api/v1alpha1/groupversion_info.go` — API group `iot.kube5s.ru/v1alpha1`
-- `iot/api/v1alpha1/zz_generated.deepcopy.go` — сгенерирован controller-gen
-- `iot/config/crd/bases/iot.kube5s.ru_iotdevices.yaml` — CRD манифест
-- `iot/controllers/iotdevice_controller.go` — контроллер с полным Reconcile loop
-- `main.go` — добавлена регистрация IoT схемы и контроллера
-
-**Проверка:** `go build ./...` — ошибок нет.
-
-**Отклонения от плана (с обоснованием):**
-- Добавлен `+kubebuilder:validation:Pattern` на `DeviceID` — необходимо чтобы имя Secret `iot-{deviceId}` было валидным k8s именем. В плане не указано, но без валидации контроллер может сломаться.
-- Использован `controllerutil.ContainsFinalizer/AddFinalizer/RemoveFinalizer` вместо ручных хелперов — более современный подход из controller-runtime. Старый код не трогал.
-- Добавлена константа `IoTDevicePhase` (типизированный string) вместо plain string в плане — для type-safety и читаемости.
-
----
-
-## Задача: Решения по архитектуре IoT MVP
-
-### Вопрос 1: Репозиторий — та же или новая?
-
-**Анализирую связи:**
-- IoT генерирует события → RabbitMQ → event-dispatcher → serverless функции
-- Связь между IoT и sless = на уровне message bus (RabbitMQ), НЕ на уровне кода
-- Общее: концепция user namespace (sless-{hash}), аутентификация (JWT→namespace)
-- Разное: домен (устройства vs функции), протоколы (MQTT vs HTTP), CRD-типы
-
-**Вариант A: Та же репа**
-- Плюс: общий go.mod, общие утилиты namespace, быстрый старт
-- Плюс: один оператор — проще деплоить для демо
-- Минус: два домена в одной репе — запутает
-- Минус: разные циклы релизов в будущем
-
-**Вариант B: Новая репа**
-- Плюс: чистое разделение, независимые релизы
-- Минус: дублирование namespace-логики или общая библиотека
-- Минус: overhead для демо слишком большой
-
-**Вариант C (мой выбор): Та же репа, изолированная структура**
-- Весь IoT-код в директории `iot/` на верхнем уровне
-- Свои контроллеры: `iot/controllers/`
-- Свои CRD: `iot/api/v1alpha1/`
-- Свой деплоймент (отдельный binary или часть того же оператора)
-- Легко вынести в отдельную репу позже — просто перемещаем `iot/`
-- Для демо: контроллеры IoT встраиваются в тот же operator binary (один pod)
-
-**Reason**: связь IoT↔sless через RabbitMQ — слабая. Код не зависит друг от друга. Но для демо удобнее держать вместе. Структура `iot/` позволяет легко разделить.
-
-### Вопрос 2: Terraform provider — расширять или новый?
-
-**Факты:**
-- Текущий провайдер: `sless` (terraform-provider-sless)
-- Ресурсы: sless_function, sless_trigger, sless_service
-- Auth: JWT → namespace
-
-**Анализ:**
-- Имя "sless" не подходит для IoT-ресурсов (`sless_iot_device` — странно)
-- Но auth/namespace логика идентична
-- Для демо: расширение существующего — быстрее всего
-- Для прода: нужен единый провайдер `nubes` (бренд облака) с подресурсами, или отдельный `nubes-iot`
-
-**Мой выбор: расширить текущий для демо**
-- Добавить `sless_iot_device`, `sless_iot_rule`
-- Имя неидеальное, но для демо ОК
-- Для прода: переименование в `nubes` — отдельная задача (breaking change)
-- Альтернатива: сразу назвать новый провайдер `nubes-iot`, но это overhead для демо
-
-**Рекомендация пользователю**: решить позже, когда IoT станет полноценным сервисом. Для демо — расширяем sless.
-
-### Вопрос 3: Scope MVP — что включаем?
-
-**Полный IoT-сервис** (для справки):
-1. MQTT-брокер ✓ 
-2. Device Registry ✓
-3. Device Auth ✓
-4. Rules Engine (маршрутизация)
-5. Time-series storage (телеметрия)
-6. Device Shadow/Twin (состояние)
-7. Command Channel (cloud→device)
-8. Dashboard/мониторинг
-
-**MVP (демо с возможностью усложнения):**
-
-ДА, включаем:
-1. ✅ EMQX — деплой через YAML/Helm в кластер
-2. ✅ CRD `IoTDevice` — имя, namespace, credentials (username/password), metadata
-3. ✅ IoT-контроллер — reconcile IoTDevice → создаёт MQTT credentials в EMQX через HTTP API
-4. ✅ EMQX → RabbitMQ bridge — маршрутизация: MQTT topic → RabbitMQ queue
-5. ✅ Включение event-триггеров в sless API (снятие блокировки)
-6. ✅ Terraform: `sless_iot_device` (CRUD)
-7. ✅ E2E демо: device → MQTT → function вызывается
-
-НЕТ, откладываем:
-- ❌ Device Shadow — усложнение, не нужно для демо
-- ❌ Rules Engine — для демо хватит простой маршрутизации topic→queue
-- ❌ Time-series storage — функция сама может писать в Postgres
-- ❌ Command channel (cloud→device) — второй этап
-- ❌ Client certificates — для демо username/password
-- ❌ Dashboard — Grafana + метрики EMQX потом
-
-### Вопрос 4: Архитектура MVP — как именно работает
-
-**Цепочка данных:**
-```
-IoT Device
-  → MQTT connect (username=deviceId, password=deviceSecret)
-  → EMQX (topic: {namespace}/telemetry/{deviceId})
-    → EMQX Rule + Bridge → RabbitMQ (queue: iot.{namespace}.{topic-pattern})
-      → sless event-dispatcher (существующий) → POST body → serverless function
-        → function обрабатывает данные
-```
-
-**Аутентификация устройств:**
-- EMQX HTTP Auth Backend → наш API: `POST /internal/mqtt/auth`
-- Контроллер при создании IoTDevice → генерирует credentials → хранит в k8s Secret
-- EMQX проверяет при MQTT CONNECT: запрос к нашему API → проверка credentials → ACL (device видит только свой namespace)
-
-**Почему EMQX HTTP Auth, а не встроенная БД:**
-- При добавлении/удалении устройства не нужно перезагружать EMQX
-- ACL динамический — привязан к namespace
-- Возможность усложнения (certificates, OAuth) без изменения EMQX
-
-**Структура файлов (план):**
-```
-iot/
-  api/v1alpha1/
-    device_types.go          # CRD IoTDevice
-    groupversion_info.go
-    zz_generated.deepcopy.go
-  controllers/
-    device_controller.go     # Reconcile: создаёт credentials, Secret
-  internal/
-    emqx/
-      client.go              # HTTP-клиент к EMQX Management API
-    mqtt_auth/
-      handler.go             # HTTP Auth Backend для EMQX
-  deployments/
-    emqx.yaml                # Деплой EMQX в кластер
-```
-
-**Что НЕ нужно создавать с нуля:**
-- RabbitMQ — есть
-- Event-dispatcher — есть (только включить event triggers)
-- Namespace-логика — есть (переиспользуем)
-- API-сервер (JWT auth, routing) — есть, добавляем IoT-эндпоинты
-
----
-
-## Вопрос: RabbitMQ vs Kafka для IoT
-
-### Контекст
-- RabbitMQ уже развёрнут, event-dispatcher написан под AMQP
-- Пользователь хочет "с прицелом на будущее, без переделок"
-- IoT = потенциально тысячи устройств, миллионы сообщений
-
-### Сравнение для IoT
-
-| Критерий | RabbitMQ | Kafka |
-|----------|----------|-------|
-| Модель | Push (broker → consumer) | Pull (consumer → offset) |
-| Хранение | Сообщение удаляется после ack | Лог хранится N дней (replay!) |
-| Масштаб | до ~50K msg/sec (один node) | миллионы msg/sec |
-| Multi-consumer | нет (сообщение потреблено = удалено) | да (разные consumer groups) |
-| IoT replay | невозможен | ключевая фича |
-| Операционные затраты | проще | сложнее (KRaft, partitions) |
-| Per-user изоляция | vhost | topic prefix, ACL |
-| Уже есть | да | нет |
-
-### Для IoT Kafka объективно лучше потому что:
-
-1. **Replay** — устройство отправило данные, функция упала → с Kafka можно перечитать. С RabbitMQ — данные потеряны (nack+requeue — не то же самое)
-2. **Multi-consumer** — одни и те же данные от датчика читают: функция-алерт, функция-аналитика, Trino (!) для запросов. С RabbitMQ нужны exchange fanout + N очередей (костыль)
-3. **Time-series природа** — IoT телеметрия = append-only лог. Kafka создан именно для этого
-4. **Масштаб** — 1000 устройств × 1 msg/sec = 1000 msg/sec (RabbitMQ справится). 100K устройств × 10 msg/sec = 1M msg/sec (RabbitMQ не справится)
-5. **Trino** — Kafka connector для Trino → SQL-запросы по потоку данных в реальном времени. С RabbitMQ этого нет
-
-### НО: event-dispatcher сейчас написан под AMQP
-
-Переход = переписать event-dispatcher. Это ~300 строк кода. Не страшно.
-
-### Мой вывод
-
-Для IoT — Kafka. Для существующих serverless event-триггеров — RabbitMQ остаётся (менять рабочее не нужно).
-
-Два брокера — нормально:
-- **RabbitMQ** — существующие event-триггеры sless (task queue: одно сообщение → одна функция)
-- **Kafka** — IoT data pipeline (stream: данные хранятся, читаются многими)
-
-Это разные паттерны использования. Не нужно одним инструментом решать обе задачи.
-
----
-
-## Вопрос: может перевести sless тоже на Kafka — пока не обросли?
-
-### Думаю вслух
-
-Пользователь прав — переделывать потом больнее. Сейчас event-dispatcher = ~300 строк, event-триггеры ещё даже не включены в API. Идеальный момент для смены.
-
-### Для sless event-триггеров: что именно нужно?
-
-Паттерн: сообщение пришло → вызвать ОДНУ функцию → подтвердить/повторить.
-
-| Нужно для sless | RabbitMQ | Kafka |
-|-----------------|----------|-------|
-| Доставка 1 сообщение → 1 функция | нативно (queue) | consumer group (работает) |
-| Retry при ошибке | nack+requeue / dead letter — нативно | нужна логика retry-topic (код) |
-| Dead letter queue | встроен | нужен отдельный topic + код |
-| Приоритеты сообщений | да | нет |
-| Задержка доставки (delay) | плагин, просто | нет нативно |
-
-RabbitMQ для task queue **объективно удобнее**. Kafka для этого работает, но требует больше кода.
-
-### НО: два брокера в проде — это боль
-
-- Два кластера мониторить
-- Два набора алертов
-- Два набора бэкапов
-- Две точки отказа
-- Двойное потребление ресурсов
-
-### Варианты
-
-**Вариант A: Два брокера (RabbitMQ для sless, Kafka для IoT)**
-- Плюс: каждый инструмент для своей задачи
-- Минус: операционная сложность × 2
-
-**Вариант B: Kafka для всего**
-- Плюс: один брокер, одна инфраструктура
-- Плюс: sless event-dispatcher переписать СЕЙЧАС — пока маленький
-- Минус: retry/DLQ для sless придётся писать руками (~50 строк)
-- Минус: Kafka тяжелее (3 ноды KRaft минимум для прода)
-
-**Вариант C: Redpanda вместо Kafka**
-- Kafka-совместимый API, но single-binary, легче в ops
-- Но менее зрелый, меньше community
-
-### Мой вывод
-
-**Kafka для всего.** Причины:
-1. Event-триггеры в sless ещё не запущены — переписать сейчас = 0 стоимости миграции
-2. Один брокер вместо двух — проще эксплуатация
-3. Retry через retry-topic — стандартный паттерн, ~50 строк кода
-4. Kafka для sless event-триггеров работает нормально (consumer group, offset commit = тот же ack)
-5. С прицелом: если sless и IoT оба на Kafka — проще интеграция (IoT event → sless function, один bus)
-
----
-
-## Контраргумент: single point of failure
-
-### Пользователь прав
-
-Если Kafka — единственный брокер и он падает → **оба сервиса мертвы** (sless event-triggers + IoT). Blast radius = вся платформа.
-
-А если два брокера:
-- Kafka упал → IoT не работает, но sless event-триггеры живы (RabbitMQ)
-- RabbitMQ упал → IoT работает, sless event-триггеры лежат
-- Полный outage = нужно чтобы упали ОБА одновременно (маловероятно)
-
-### Пересмотр решения
-
-Это классический trade-off: операционная простота vs отказоустойчивость.
-
-Для managed service платформы — **отказоустойчивость важнее**. Клиент платит за uptime.
-
-### Финальное решение: ДВА брокера
-
-- **RabbitMQ** → sless event-триггеры (уже написан, проще для task queue, независимый)
-- **Kafka** → IoT pipeline (replay, multi-consumer, масштаб)
-- Изоляция fault domains: падение одного не убивает другой сервис
-
-Операционная сложность двух брокеров — приемлемая цена за изоляцию.
-Мониторинг/алерты — решаемо (Prometheus + Grafana для обоих).
-
----
-
-## Реальность: кубер сломан, выходные, нет облачных сервисов
-
-### Ситуация
-- Реалм пользователя не создаёт managed-сервисы (баг/инцидент)
-- До понедельника никого нет (шабат/выходные)
-- Kafka может оказаться в другом реалме, чем RabbitMQ
-- Нужно работать с тем что есть СЕЙЧАС
-
-### Мои мысли
-
-**Вариант A: Делаем MVP на RabbitMQ (который есть)**
-- Плюс: RabbitMQ уже работает, ничего разворачивать не нужно
-- Плюс: event-dispatcher уже написан под AMQP
-- Плюс: можно прямо сейчас начать IoT-часть (CRD, контроллер, EMQX, bridge)
-- Плюс: demo будет работать к понедельнику
-- Минус: потом нужна миграция EMQX→Kafka вместо EMQX→RabbitMQ bridge
-- НО: мост MQTT→broker — это конфиг EMQX, а не наш код. Переключить EMQX bridge с RabbitMQ на Kafka = смена конфига, не переписывание
-
-**Вариант B: Поднять Kafka руками в кубере (Strimzi/Bitnami Helm)**
-- Плюс: правильная архитектура с самого начала
-- Минус: Kafka в k8s = тяжело (3 ноды KRaft, storage, сетевые проблемы)
-- Минус: если реалм глючит — может и Kafka не развернуться
-- Минус: потом всё равно мигрировать на managed
-
-**Вариант C (мой выбор): MVP на RabbitMQ сейчас, архитектура ready for Kafka**
-
-Суть: делаем IoT bridge через абстракцию, не привязываясь к конкретному брокеру.
-
-```
-EMQX → [bridge config] → RabbitMQ (сейчас)
-                        → Kafka (потом, смена конфига)
-
-IoT event consumer → [interface] → POST → function
-  сейчас: event-dispatcher (AMQP) уже есть
-  потом:  iot-consumer (Kafka) — отдельный сервис
-```
-
-Ключевое: НАША кодовая база НЕ зависит от выбора брокера.
-- CRD IoTDevice — не зависит
-- IoT контроллер — не зависит  
-- MQTT auth — не зависит
-- EMQX — bridge настраивается конфигом (RabbitMQ или Kafka)
-- Единственная точка замены: consumer, который читает из брокера и POST в функцию
-
-### Что менять при переходе RabbitMQ → Kafka
-
-1. EMQX bridge config: `rabbitmq` → `kafka` (конфиг, не код)
-2. Consumer: отдельный iot-event-consumer вместо reuse event-dispatcher (~200 строк Go)
-3. Kafka deployment: managed или Strimzi
-
-Всё. Наш IoT-оператор, CRD, device auth — не меняются вообще.

examples/.gitignore

@@ -1,5 +1,5 @@
-# Created: 2026-03-11 / Updated: 2026-03-30
-# Purpose: ignore generated artifacts and internal files for the `examples` repository
+# Created: 2026-03-11
+# Purpose: ignore generated artifacts for the `examples` repository
 
 # Terraform
 .terraform/
@@ -16,7 +16,6 @@ crash.log
 # Provider plugins / caches
 .terraform.d/
 
-# tfvars содержат секреты (токены, ключи) — пользователь создаёт из .template
 *.tfvars
 
 # Archives and build artifacts
@@ -40,34 +39,3 @@ venv/
 .env
 *.local
 *.log
-
-# ---- SSH-ключи (секретные данные, у каждого пользователя свои) ----
-vm_key
-vm_key.pub
-**/vm_key
-**/vm_key.pub
-*.pem
-id_ed25519
-id_rsa
-
-# ---- Внутренние тестовые и служебные скрипты (не для пользователей) ----
-# VM
-VM/vm_stress_test.sh
-VM/.vm_stress_test.sh.OLD
-VM/VM_TEST_README.md
-
-# POSTGRES
-POSTGRES/vm_stress_test.sh
-POSTGRES/stress_test.sh
-POSTGRES/stress_destroy_apply.sh.disabled
-POSTGRES/full_test.sh
-POSTGRES/bug_hunter.sh
-POSTGRES/chaos_marathon.sh
-POSTGRES/test_cache_matrix.sh
-POSTGRES/deploy_and_run_chaos.sh
-POSTGRES/scripts/
-
-# ---- Примеры в разработке (временно скрыты) ----
-POSTGRES/
-NODEJS/
-DEVfromGround/

examples/DEVfromGround/main.tf

@@ -1,28 +0,0 @@
-// 2026-03-26 — main.tf: провайдер Nubes для DEV-стенда.
-// DEV API endpoint: https://deck-api-dev.ngcloud.ru/api/v1
-// Токен: secrets/dev.token (tazet@narod.ru)
-
-terraform {
-  required_providers {
-    nubes = {
-      source  = "terra.k8c.ru/nubes/nubes"
-      version = "5.0.31"
-    }
-  }
-}
-
-variable "api_token" {
-  type        = string
-  sensitive   = true
-  description = "Nubes API токен (DEV-стенд). Значение — в terraform.tfvars."
-}
-
-variable "resource_realm" {
-  type        = string
-  description = "Платформа развёртывания (например k8s-3.ext.nubes.ru). Уточнить у сервис-менеджера."
-}
-
-provider "nubes" {
-  api_token    = var.api_token
-  api_endpoint = "https://deck-api-dev.ngcloud.ru/api/v1/index.cfm"
-}

examples/DEVfromGround/vc_org.tf

@@ -1,34 +0,0 @@
-// 2026-03-26 — vc_org.tf: ресурс «Организация в Cloud Director» для DEV-стенда.
-// nubes_vc_org — тенант vCloud Director (organization_type = "iaas").
-// resource_realm задаётся через переменную (terraform.tfvars или -var).
-
-resource "nubes_vc_org" "dev_org" {
-  resource_name  = "vcOrg-2"
-  resource_realm = var.resource_realm
-
-  # organization_type "iaas" — единственный вариант с доступом к организации.
-  # Значение по умолчанию "iaas", явно прописано для читаемости.
-  organization_type = "iaas"
-
-  # v_i_p_configure — JSON-список ipSpaces для операции modify.
-  # При create провайдер не передаёт его в API, но требует non-null значение в плане.
-  v_i_p_configure = ""
-
-  # adopt_existing_on_create = true — берёт существующий инстанс (dev-org-sless-demo уже создан с null realm от предыдущей попытки).
-  adopt_existing_on_create = true
-
-  # suspend_on_destroy = true (по умолчанию) — при destroy инстанс уходит в Suspend, не удаляется.
-  suspend_on_destroy = true
-}
-
-# ─── Outputs ─────────────────────────────────────────────────────────────────
-
-output "dev_org_id" {
-  description = "ID созданной организации (используется в зависимых ресурсах)"
-  value       = nubes_vc_org.dev_org.id
-}
-
-output "dev_org_state_flat" {
-  description = "Плоский state организации — endpoints, статусы"
-  value       = nubes_vc_org.dev_org.state_out_flat
-}

examples/IOT/README.md

@@ -1,83 +0,0 @@
-# IoT MVP — E2E Demo
-
-## Что делает этот пример
-
-Показывает полную цепочку:
-
-```
-IoT Device (mosquitto_pub)
-  → MQTT PUBLISH → EMQX (HTTP auth → sless-operator)
-    → [iot-mqtt-bridge подписан на "+/telemetry/+"]
-      → RabbitMQ queue "iot.{namespace}.telemetry"
-        → event-dispatcher
-          → POST → serverless function (handler.py)
-```
-
-## Предусловия
-
-1. EMQX запущен: `kubectl apply -f deployments/k8s/emqx.yaml`
-2. iot-mqtt-bridge запущен: `kubectl apply -f deployments/k8s/iot-mqtt-bridge.yaml`
-3. event-dispatcher запущен (уже должен работать)
-
-## Запуск
-
-```bash
-# Установить переменные
-export API_TOKEN="your-jwt-token"
-export NAMESPACE="sless-abc123def456"  # твой namespace
-
-# Инициализировать
-terraform init
-terraform apply \
-  -var="namespace=${NAMESPACE}" \
-  -var="api_token=${API_TOKEN}"
-
-# Получить credentials
-MQTT_USER=$(terraform output -raw mqtt_username)
-MQTT_PASS=$(terraform output -raw mqtt_password)
-MQTT_TOPIC=$(terraform output -raw mqtt_topic)
-
-echo "MQTT user: ${MQTT_USER}"
-echo "MQTT topic: ${MQTT_TOPIC}"
-```
-
-## Отправить тестовое сообщение
-
-```bash
-# Через mosquitto_pub (из пода внутри кластера)
-kubectl run mqtt-test --rm -i --image=eclipse-mosquitto --restart=Never -- \
-  mosquitto_pub \
-  -h emqx.sless.svc \
-  -p 1883 \
-  -u "${MQTT_USER}" \
-  -P "${MQTT_PASS}" \
-  -t "${MQTT_TOPIC}" \
-  -m '{"temperature": 22.5, "humidity": 65, "unit": "celsius"}'
-```
-
-## Проверить что функция вызвалась
-
-```bash
-# Логи event-dispatcher
-kubectl logs -n sless deployment/event-dispatcher -f
-
-# Логи функции (через invocations API)
-curl -H "Authorization: Bearer ${API_TOKEN}" \
-  https://sless.kube5s.ru/v1/namespaces/${NAMESPACE}/functions/iot-telemetry-handler/invocations
-```
-
-## Структура файлов
-
-```
-examples/IOT/
-  main.tf      # Terraform: function + trigger + iot_device
-  handler.py   # Python обработчик телеметрии
-  README.md    # Этот файл
-```
-
-## Известные ограничения MVP
-
-- `sless_iot_device` Terraform ресурс требует реализации в terraform-provider-sless (Этап 6)
-- EMQX TLS отключён — включить для prod (настроить cert-manager secret)
-- iot-mqtt-bridge credentials создаются вручную (автоматизировать в будущем)
-- Нет обратного канала: Cloud → Device команды (Device Shadow — вне MVP)

examples/IOT/handler.py

@@ -1,57 +0,0 @@
-"""
-Создано: 2026-04-04
-handler.py — обработчик IoT-телеметрии для демонстрации IoT MVP.
-
-Вызывается event-dispatcher при каждом MQTT сообщении от устройства.
-Входящий event.body содержит JSON сформированный mqtt-bridge:
-{
-  "namespace": "sless-abc123",
-  "device_id": "temp-sensor-01",
-  "topic": "sless-abc123/telemetry/temp-sensor-01",
-  "payload": {"temperature": 22.5, "humidity": 65},
-  "received_at": "2026-04-04T12:00:00Z"
-}
-"""
-
-import json
-import os
-
-
-def handle(event, context):
-    """Обработчик телеметрии IoT-устройства.
-    
-    Логирует данные и возвращает подтверждение.
-    В реальном сценарии здесь: сохранение в БД, алертинг, управляющие команды.
-    """
-    log_level = os.getenv("LOG_LEVEL", "INFO")
-
-    try:
-        body = json.loads(event.get("body", "{}"))
-    except json.JSONDecodeError as e:
-        return {
-            "statusCode": 400,
-            "body": json.dumps({"error": f"invalid JSON: {e}"})
-        }
-
-    namespace = body.get("namespace", "unknown")
-    device_id = body.get("device_id", "unknown")
-    payload = body.get("payload", {})
-    received_at = body.get("received_at", "")
-
-    if log_level == "INFO":
-        print(f"[IoT] namespace={namespace} device={device_id} at={received_at}")
-        print(f"[IoT] payload={json.dumps(payload)}")
-
-    # Здесь добавить бизнес-логику:
-    # - Запись в PostgreSQL (через POSTGRES_DSN из env)
-    # - Проверка порогов и алертинг
-    # - Публикация управляющей команды обратно на устройство
-
-    return {
-        "statusCode": 200,
-        "body": json.dumps({
-            "processed": True,
-            "device_id": device_id,
-            "namespace": namespace,
-        })
-    }

examples/IOT/main.tf

@@ -1,102 +0,0 @@
-# Создано: 2026-04-04
-# E2E Demo: IoT Device → MQTT → RabbitMQ → Serverless Function
-#
-# Порядок применения:
-#   1. terraform init
-#   2. terraform apply
-#   3. Получить credentials: terraform output mqtt_password
-#   4. Отправить тестовое MQTT сообщение (см. README.md ниже)
-
-terraform {
-  required_providers {
-    sless = {
-      source  = "kube5s.ru/naeel/sless"
-      version = ">= 0.1"
-    }
-  }
-}
-
-# Адрес API sless оператора
-provider "sless" {
-  api_url = "https://sless.kube5s.ru"
-}
-
-# Переменные
-variable "namespace" {
-  description = "Namespace пользователя (создаётся через EnsureNamespace)"
-  type        = string
-}
-
-variable "api_token" {
-  description = "JWT токен для аутентификации в sless API"
-  type        = string
-  sensitive   = true
-}
-
-# Python функция-обработчик IoT-телеметрии
-resource "sless_function" "iot_telemetry_handler" {
-  namespace   = var.namespace
-  name        = "iot-telemetry-handler"
-  runtime     = "python3.11"
-  entrypoint  = "handler.handle"
-  memory_mb   = 128
-  timeout_sec = 30
-
-  env_vars = {
-    LOG_LEVEL = "INFO"
-  }
-}
-
-# Event Trigger: подписка на IoT telemetry queue
-# event-dispatcher читает из этой очереди и вызывает функцию
-resource "sless_trigger" "iot_telemetry_trigger" {
-  namespace    = var.namespace
-  name         = "iot-telemetry-events"
-  type         = "event"
-  function_ref = sless_function.iot_telemetry_handler.name
-  # queue = "iot.{namespace}.telemetry" — формируется mqtt-bridge автоматически
-  queue        = "iot.${var.namespace}.telemetry"
-  enabled      = true
-}
-
-# IoT устройство — температурный датчик
-resource "sless_iot_device" "temperature_sensor" {
-  namespace = var.namespace
-  name      = "temperature-sensor"
-  device_id = "temp-sensor-01"
-  enabled   = true
-
-  metadata = {
-    model    = "DHT22"
-    location = "server-room"
-    owner    = "ops-team"
-  }
-}
-
-# ——— Outputs ———
-
-output "mqtt_broker" {
-  value       = "emqx.sless.svc:1883"
-  description = "MQTT broker адрес (доступен внутри кластера)"
-}
-
-output "mqtt_username" {
-  value       = sless_iot_device.temperature_sensor.mqtt_username
-  description = "MQTT username для устройства"
-}
-
-output "mqtt_password" {
-  value       = sless_iot_device.temperature_sensor.mqtt_password
-  sensitive   = true
-  description = "MQTT пароль для устройства (sensitive)"
-}
-
-output "mqtt_topic" {
-  value       = "${var.namespace}/telemetry/temp-sensor-01"
-  description = "MQTT topic для публикации телеметрии"
-}
-
-output "iot_device_phase" {
-  value       = sless_iot_device.temperature_sensor.phase
-  description = "Статус IoT устройства (Active/Pending/Disabled/Error)"
-}

examples/NODEJS/main.tf

@@ -1,32 +0,0 @@
-// Создано: 2026-03-23
-// main.tf — провайдер Nubes + переменные для примера NODEJS.
-// Ресурс nubes_nodejs: managed Node.js приложение в облаке (не sless-функция).
-
-terraform {
-  required_providers {
-    nubes = {
-      source  = "terra.k8c.ru/nubes/nubes"
-      version = "5.0.19"
-    }
-  }
-}
-
-variable "api_token" {
-  type      = string
-  sensitive = true
-}
-
-variable "realm" {
-  type        = string
-  description = "resource_realm — зона размещения ресурса (например: k8s-3-sandbox-nubes-ru)"
-}
-
-variable "git_path" {
-  type        = string
-  description = "URL git-репозитория с кодом приложения"
-}
-
-provider "nubes" {
-  api_token    = var.api_token
-  api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
-}

examples/NODEJS/nodejs.tf

@@ -1,22 +0,0 @@
-# Создано: 2026-03-23
-# nodejs.tf — ресурс nubes_nodejs: managed Node.js приложение.
-# Параметры взяты из документации terra.k8c.ru/docs/nubes/nubes/5.0.19/30_registry/resources/nodejs_params_create/
-
-resource "nubes_nodejs" "app" {
-  resource_name      = "nodejsdemo1"
-  domain             = "domma"
-  resource_realm     = var.realm
-  git_path           = var.git_path
-  app_version        = "23"
-  resource_c_p_u     = 500
-  resource_memory    = 1024
-  resource_instances = 1
-  json_env           = jsonencode({})
-  adopt_existing_on_create  = true
-  # health_path не задан — используется дефолтный /
-}
-
-output "nodejs_domain" {
-  description = "Домен развёрнутого Node.js приложения"
-  value       = nubes_nodejs.app.domain
-}

examples/PG_TEST/.gitignore

@@ -1,21 +0,0 @@
-# Terraform provider plugins
-.terraform/
-.terraform.lock.hcl
-
-# Terraform state
-terraform.tfstate
-terraform.tfstate.backup
-*.tfstate
-*.tfstate.backup
-
-# Sensitive data
-terraform.tfvars
-!terraform.tfvars.example
-
-# Backup files
-*.bak
-*.bak_db
-*.bak_*
-
-# Test artifacts
-test_*.log

examples/PG_TEST/main.tf

@@ -1,59 +0,0 @@
-// 2026-04-01 — main.tf: провайдеры и объявления переменных.
-// Этот файл не нужно редактировать. Все настройки — в terraform.tfvars.
-
-terraform {
-  required_providers {
-    nubes = {
-      source  = "terra.k8c.ru/nubes/nubes"
-      version = "5.0.55"
-    }
-  }
-}
-
-// ── Объявления переменных ─────────────────────────────────────────────────────
-// Значения задаются в terraform.tfvars — не трогать этот файл.
-
-variable "api_token" {
-  type        = string
-  sensitive   = true
-  description = "Nubes API token"
-}
-
-variable "s3_uid" {
-  type        = string
-  sensitive   = true
-  description = "UUID S3-bucket для бэкапов PostgreSQL"
-}
-
-variable "realm" {
-  type        = string
-  description = "Realm — идентификатор зоны/проекта в Nubes"
-}
-
-variable "pg_resource_name" {
-  type        = string
-  description = "Имя инстанса PostgreSQL (уникально в рамках realm)"
-}
-
-variable "pg_username" {
-  type        = string
-  description = "Имя пользователя PostgreSQL"
-}
-
-variable "pg_db_name" {
-  type        = string
-  description = "Имя создаваемой базы данных"
-}
-
-variable "pg_role" {
-  type        = string
-  description = "Роль пользователя"
-}
-
-// ── Провайдер ─────────────────────────────────────────────────────────────────
-
-provider "nubes" {
-  api_token    = var.api_token
-  log_level    = "debug"
-  api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
-}

examples/PG_TEST/outputs.tf

@@ -1,42 +0,0 @@
-// 2026-04-01 — outputs.tf: данные подключения к PostgreSQL после apply.
-//
-// Пароль не выводим напрямую — только через sensitive output (не появляется
-// в логах CI по умолчанию). Для явного показа: terraform output pg_password
-
-output "pg_instance_id" {
-  description = "ID инстанса PostgreSQL в Nubes"
-  value       = nubes_postgres.pg_test_instance.id
-}
-
-output "pg_host" {
-  description = "Внутренний адрес master-ноды PostgreSQL"
-  value       = local.pg_host
-}
-
-output "pg_port" {
-  description = "Порт PostgreSQL"
-  value       = local.pg_port
-}
-
-output "pg_database" {
-  description = "Имя базы данных"
-  value       = nubes_postgres_database.pg_test_db.db_name
-}
-
-output "pg_username" {
-  description = "Имя пользователя PostgreSQL"
-  value       = nubes_postgres_user.pg_test_user.username
-}
-
-output "pg_password" {
-  description = "Пароль пользователя из vault_secrets (пустой на первом apply — заполнится на следующем)"
-  value       = local.pg_password
-  sensitive   = true
-}
-
-// Удобная строка подключения — для psql или приложений.
-output "pg_dsn" {
-  description = "DSN для подключения: postgresql://user:pass@host:port/db"
-  value       = "postgresql://${nubes_postgres_user.pg_test_user.username}:${local.pg_password}@${local.pg_host}:${local.pg_port}/${nubes_postgres_database.pg_test_db.db_name}"
-  sensitive   = true
-}

examples/PG_TEST/postgres.tf

@@ -1,99 +0,0 @@
-// 2026-04-01 — postgres.tf: Managed PostgreSQL инстанс, пользователь и база данных.
-//
-// Порядок создания:
-//   1. nubes_postgres      — сам инстанс PostgreSQL
-//   2. nubes_postgres_user — пользователь; пароль автоматически попадает в vault_secrets
-//   3. nubes_postgres_database — база данных с owner = созданный пользователь
-//
-// Важно: vault_secrets["users"] появляется только ПОСЛЕ первого apply (нет пользователя — нет ключа).
-//        try() в locals страхует от ошибки на первом прогоне.
-
-// ── Locals: credentials из vault ─────────────────────────────────────────────
-
-locals {
-  # Карта username→{password, username} из vault_secrets, который Nubes заполняет после
-  # создания пользователя. try() нужен для первого apply, когда ключа ещё нет.
-  pg_creds_map = try(
-    jsondecode(lookup(nubes_postgres.pg_test_instance.vault_secrets, "users", "{}")),
-    {}
-  )
-  pg_password = try(local.pg_creds_map[var.pg_username]["password"], "")
-
-  # Адрес master-ноды (внутренний — для подключения из кластера).
-  pg_host = nubes_postgres.pg_test_instance.state_out_flat["internalConnect.master"]
-  pg_port = 5432
-}
-
-// ── Инстанс PostgreSQL ────────────────────────────────────────────────────────
-
-resource "nubes_postgres" "pg_test_instance" {
-  resource_name  = var.pg_resource_name
-  s3_uid         = var.s3_uid
-  resource_realm = var.realm
-
-  # Минимальные ресурсы — достаточно для тестирования.
-  resource_instances = 1
-  resource_memory    = 512 # MiB
-  resource_c_p_u     = 500 # millicores
-  resource_disk      = "1" # GiB
-  app_version        = "17"
-
-  # json_parameters убран — при передаче пустого объекта API возвращает "Invalid JSON String".
-  # Если нужны кастомные параметры PG — добавить после диагностики.
-
-  # Pooler не нужен для тестов — упрощает топологию.
-  enable_pg_pooler_master = false
-  enable_pg_pooler_slave  = false
-
-  allow_no_s_s_l         = false
-  auto_scale             = false
-  auto_scale_percentage  = 10
-  auto_scale_tech_window = 0
-  auto_scale_quota_gb    = "1"
-
-  # Внешний адрес не нужен — подключаемся изнутри кластера.
-  need_external_address_master = false
-
-  operation_timeout = "11m"
-
-  # Позволяет импортировать уже существующий инстанс с тем же именем, не падая
-  # с "already exists" — удобно при повторном apply после ручного создания.
-  adopt_existing_on_create = true
-}
-
-// ── Пользователь ──────────────────────────────────────────────────────────────
-
-resource "nubes_postgres_user" "pg_test_user" {
-  postgres_id = nubes_postgres.pg_test_instance.id
-  username    = var.pg_username
-  role        = var.pg_role
-
-  # Не падать если пользователь с таким именем уже существует.
-  adopt_existing_on_create = true
-}
-
-resource "nubes_postgres_user" "pg_test_user3" {
-  postgres_id = nubes_postgres.pg_test_instance.id
-  username    = "u3"
-  role        = var.pg_role
-
-  depends_on = [nubes_postgres_user.pg_test_user]
-  # Не падать если пользователь с таким именем уже существует.
-  adopt_existing_on_create = true
-}
-
-// ── База данных ───────────────────────────────────────────────────────────────
-
-resource "nubes_postgres_database" "pg_test_db" {
-  postgres_id = nubes_postgres.pg_test_instance.id
-  db_name     = var.pg_db_name
-  db_owner    = nubes_postgres_user.pg_test_user.username
-
-  # Не падать если БД уже существует.
-  adopt_existing_on_create = true
-
-  # ВАЖНО: из-за ограничения API Nubes (ERR-PG-08: "Concurrent operations are not supported")
-  # нужно явно ждать пользователя даже если он не выглядит dependency.
-  # других ресурс на инстансе ещё обрабатывает операции.
-  depends_on = [nubes_postgres_user.pg_test_user3]
-}

examples/PG_TEST/terraform.tfvars.example

@@ -1,54 +0,0 @@
-# =============================================================================
-# 2026-04-01 — terraform.tfvars
-#
-# ЕДИНСТВЕННЫЙ файл, который нужно заполнить перед запуском.
-# Остальные .tf-файлы не трогать.
-#
-# Как запустить:
-#   1. Скопировать этот файл:  cp terraform.tfvars.example terraform.tfvars
-#   2. Заполнить три обязательных поля ниже (ЗАПОЛНИТЬ)
-#   3. terraform init
-#   4. terraform apply
-#
-# После apply — увидеть данные подключения:
-#   terraform output pg_host
-#   terraform output pg_database
-#   terraform output pg_username
-#   terraform output -raw pg_password   # пароль (показывается явно только с -raw)
-#   terraform output -raw pg_dsn        # полная строка подключения
-# =============================================================================
-
-
-# =============================================================================
-# ОБЯЗАТЕЛЬНО ЗАПОЛНИТЬ
-# =============================================================================
-
-# API-токен из личного кабинета Nubes.
-# Где взять: https://deck-test.ngcloud.ru/ → Профиль → API-токены
-api_token = "ЗАПОЛНИТЬ"
-
-# UUID вашего S3-бакета — нужен PostgreSQL для хранения бэкапов.
-# Пример: "332cdb0d-****-43bf-****-4adcc3b5****"
-s3_uid = "ЗАПОЛНИТЬ"
-
-# Realm — идентификатор вашей зоны/проекта.
-# Пример: "k8s-3-sandbox-nubes-ru"
-realm = "ЗАПОЛНИТЬ"
-
-
-# =============================================================================
-# МОЖНО ОСТАВИТЬ КАК ЕСТЬ (изменить при необходимости)
-# =============================================================================
-
-# Имя PostgreSQL-инстанса в Nubes.
-# Должно быть уникальным в рамках realm. Менять если создаёте несколько стендов.
-pg_resource_name = "pg-test-01"
-
-# Имя пользователя базы данных.
-pg_username = "pgtest_user"
-
-# Имя базы данных.
-pg_db_name = "pgtest_db"
-
-# Роль пользователя. 
-pg_role = "ddl_user"

examples/PG_TEST/test_basic.sh

@@ -1,49 +0,0 @@
-#!/usr/bin/env bash
-# 2026-04-01 — test_basic.sh: простая проверка что ресурсы созданы и outputs заполнены.
-# Не делает apply/destroy — только читает state и outputs.
-# Запуск: bash test_basic.sh
-
-set -uo pipefail
-DIR="$(cd "$(dirname "$0")" && pwd)"
-cd "$DIR"
-
-GREEN="\033[0;32m"; RED="\033[0;31m"; NC="\033[0m"
-PASS=0; FAIL=0
-
-ok()   { echo -e "${GREEN}PASS${NC} $1"; PASS=$((PASS+1)); }
-fail() { echo -e "${RED}FAIL${NC} $1"; FAIL=$((FAIL+1)); }
-
-echo "=== PG_TEST basic check — $(date '+%Y-%m-%d %H:%M:%S') ==="
-echo ""
-
-# ── 1. Нужные ресурсы есть в state ───────────────────────────────────────────
-echo "--- state ---"
-for res in \
-  "nubes_postgres.pg_test_instance" \
-  "nubes_postgres_user.pg_test_user" \
-  "nubes_postgres_database.pg_test_db"
-do
-  if terraform state show "$res" > /dev/null 2>&1; then
-    ok "state: $res"
-  else
-    fail "state: $res — не найден"
-  fi
-done
-
-echo ""
-
-# ── 2. Outputs непустые ───────────────────────────────────────────────────────
-echo "--- outputs ---"
-
-pg_host=$(terraform output -raw pg_host 2>/dev/null || true)
-pg_db=$(terraform output -raw pg_database 2>/dev/null || true)
-pg_user=$(terraform output -raw pg_username 2>/dev/null || true)
-pg_pass=$(terraform output -raw pg_password 2>/dev/null || true)
-
-[[ -n "$pg_host" ]]  && ok "pg_host = $pg_host"     || fail "pg_host пустой"
-[[ -n "$pg_db" ]]    && ok "pg_database = $pg_db"   || fail "pg_database пустой"
-[[ -n "$pg_user" ]]  && ok "pg_username = $pg_user" || fail "pg_username пустой"
-[[ -n "$pg_pass" ]]  && ok "pg_password непустой"   || fail "pg_password пустой (возможно нужен повторный apply)"
-
-echo ""
-echo "=== Итог: PASS=$PASS FAIL=$FAIL ==="

examples/PG_TEST/test_lifecycle.sh

@@ -1,187 +0,0 @@
-#!/usr/bin/env bash
-# 2026-04-01 — test_lifecycle.sh
-# Гоняет реальный API Nubes: создание/удаление/модификация пользователей и БД.
-# Каждый шаг — отдельный terraform apply с живым выводом.
-# Запуск: bash test_lifecycle.sh
-
-set -uo pipefail
-DIR="$(cd "$(dirname "$0")" && pwd)"
-cd "$DIR"
-
-GREEN="\033[0;32m"; RED="\033[0;31m"; YELLOW="\033[1;33m"; CYAN="\033[0;36m"; NC="\033[0m"
-PASS=0; FAIL=0
-
-ok()      { echo -e "\n${GREEN}>>> PASS${NC} $1"; PASS=$((PASS+1)); }
-fail()    { echo -e "\n${RED}>>> FAIL${NC} $1"; FAIL=$((FAIL+1)); }
-section() { echo -e "\n${YELLOW}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n  $1\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"; }
-step()    { echo -e "\n${CYAN}--- $1 ---${NC}"; }
-
-# run_apply — terraform apply с живым выводом в терминал.
-run_apply() {
-  echo ""
-  terraform apply -auto-approve
-  return $?
-}
-
-# run_apply_expect_fail — apply должен упасть (ошибка API = успех теста).
-run_apply_expect_fail() {
-  local label="$1"
-  echo ""
-  if terraform apply -auto-approve; then
-    fail "$label — ожидали ошибку API, но apply прошёл!"
-  else
-    ok "$label — API вернул ошибку (ожидаемо)"
-  fi
-}
-
-echo -e "\n${YELLOW}╔══════════════════════════════════════════════════════╗"
-echo    "║  PG_TEST lifecycle — $(date '+%Y-%m-%d %H:%M:%S')    ║"
-echo -e "╚══════════════════════════════════════════════════════╝${NC}"
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 0 — Очистка: destroy всего перед стартом"
-# ─────────────────────────────────────────────────────────────────────────────
-# Гарантируем чистый старт — убираем все ресурсы и state.
-step "terraform destroy (убираем всё что осталось от предыдущих прогонов)"
-terraform destroy -auto-approve || true   # не падаем если уже пусто
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 1 — Создать: 2 пользователя + 2 БД + 1 app_user"
-# ─────────────────────────────────────────────────────────────────────────────
-step "terraform apply (postgres.tf + postgres_extra.tf)"
-if run_apply; then
-  ok "Создание прошло"
-else
-  fail "Создание упало — дальше не идём"
-  exit 1
-fi
-echo ""; echo "Ресурсы в state:"; terraform state list | grep -v pg_test_instance
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 2 — Удалить extra_user2 и extra_db2"
-# ─────────────────────────────────────────────────────────────────────────────
-step "Убираем test_extra_user2 и test_extra_db2 из tf"
-python3 - <<'PYEOF'
-import re, pathlib
-
-def comment_block(path, resource_type, resource_name):
-    text = pathlib.Path(path).read_text()
-    pattern = rf'(resource\s+"{re.escape(resource_type)}"\s+"{re.escape(resource_name)}"\s*\{{)'
-    match = re.search(pattern, text)
-    if not match:
-        print(f"  WARNING: {resource_type}.{resource_name} not found"); return
-    start = match.start(); depth, i = 0, start
-    while i < len(text):
-        if text[i] == '{': depth += 1
-        elif text[i] == '}':
-            depth -= 1
-            if depth == 0: end = i + 1; break
-        i += 1
-    pathlib.Path(path).write_text(
-        text[:start] + "/* DISABLED\n" + text[start:end] + "\nDISABLED */" + text[end:]
-    )
-    print(f"  скрыт: {resource_type}.{resource_name}")
-
-comment_block("postgres_extra.tf", "nubes_postgres_user", "test_extra_user2")
-comment_block("postgres_extra.tf", "nubes_postgres_database", "test_extra_db2")
-PYEOF
-
-step "terraform apply — API удаляет user2 и db2"
-if run_apply; then ok "Удаление прошло"; else fail "Удаление упало"; fi
-echo ""; echo "Ресурсы в state:"; terraform state list | grep -v pg_test_instance
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 3 — Воссоздать extra_user2 и extra_db2"
-# ─────────────────────────────────────────────────────────────────────────────
-step "Восстанавливаем tf"
-python3 - <<'PYEOF'
-import pathlib, re
-p = pathlib.Path("postgres_extra.tf")
-text = re.sub(r'/\* DISABLED\n', '', p.read_text())
-text = re.sub(r'\nDISABLED \*/', '', text)
-p.write_text(text); print("  postgres_extra.tf восстановлен")
-PYEOF
-
-step "terraform apply — API воссоздаёт user2 и db2"
-if run_apply; then ok "Воссоздание прошло"; else fail "Воссоздание упало"; fi
-echo ""; echo "Ресурсы в state:"; terraform state list | grep -v pg_test_instance
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 4 — Модификация: сменить db_owner у extra_db1"
-# ─────────────────────────────────────────────────────────────────────────────
-step "db_owner test_extra_db1: extra_user1 → extra_user2"
-python3 - <<'PYEOF'
-import pathlib
-p = pathlib.Path("postgres_extra.tf")
-text = p.read_text().replace(
-    'nubes_postgres_user.test_extra_user1.username',
-    'nubes_postgres_user.test_extra_user2.username', 1)
-p.write_text(text); print("  db_owner: user1 → user2")
-PYEOF
-
-step "terraform apply — API обновляет db_owner"
-if run_apply; then ok "Смена db_owner прошла"; else fail "Смена db_owner упала"; fi
-
-step "Откат db_owner обратно (user2 → user1)"
-python3 - <<'PYEOF'
-import pathlib
-p = pathlib.Path("postgres_extra.tf")
-text = p.read_text().replace(
-    'nubes_postgres_user.test_extra_user2.username',
-    'nubes_postgres_user.test_extra_user1.username', 1)
-p.write_text(text); print("  db_owner: user2 → user1")
-PYEOF
-run_apply > /dev/null 2>&1 || true
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 5 — Невалидные параметры: ждём ошибку API"
-# ─────────────────────────────────────────────────────────────────────────────
-step "Тест 5a: db_owner = несуществующий пользователь"
-cat > ./pg_test_invalid.tf <<'TFEOF'
-resource "nubes_postgres_database" "test_invalid_owner" {
-  postgres_id              = nubes_postgres.pg_test_instance.id
-  db_name                  = "invalid_owner_db"
-  db_owner                 = "this_user_does_not_exist"
-  adopt_existing_on_create = false
-}
-TFEOF
-run_apply_expect_fail "5a: db_owner='this_user_does_not_exist'"
-rm -f ./pg_test_invalid.tf; run_apply > /dev/null 2>&1 || true
-
-step "Тест 5b: role = несуществующая строка"
-cat > ./pg_test_invalid.tf <<'TFEOF'
-resource "nubes_postgres_user" "test_invalid_role" {
-  postgres_id              = nubes_postgres.pg_test_instance.id
-  username                 = "invalid_role_user"
-  role                     = "fantasy_role_xyz"
-  adopt_existing_on_create = false
-}
-TFEOF
-run_apply_expect_fail "5b: role='fantasy_role_xyz'"
-rm -f ./pg_test_invalid.tf; run_apply > /dev/null 2>&1 || true
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ШАГ 6 — app_user пытается стать db_owner"
-# ─────────────────────────────────────────────────────────────────────────────
-# app_user — базовые права. Нельзя быть db_owner — это прерогатива ddl_user.
-step "Тест 6a: test_app_user (role=app_user) назначается db_owner"
-cat > ./pg_test_invalid.tf <<'TFEOF'
-resource "nubes_postgres_database" "test_appuser_as_owner" {
-  postgres_id              = nubes_postgres.pg_test_instance.id
-  db_name                  = "appuser_owned_db"
-  db_owner                 = nubes_postgres_user.test_app_user.username
-  adopt_existing_on_create = false
-}
-TFEOF
-run_apply_expect_fail "6a: app_user как db_owner — API должен отклонить"
-rm -f ./pg_test_invalid.tf; run_apply > /dev/null 2>&1 || true
-
-# ─────────────────────────────────────────────────────────────────────────────
-section "ИТОГ"
-# ─────────────────────────────────────────────────────────────────────────────
-echo ""
-echo -e "  PASS: ${GREEN}${PASS}${NC}  FAIL: ${RED}${FAIL}${NC}"
-echo ""
-[[ "$FAIL" -eq 0 ]] \
-  && echo -e "${GREEN}Все тесты прошли.${NC}" \
-  || echo -e "${RED}Есть ошибки — проверь вывод выше.${NC}"

examples/POSTGRES/code/calc-node/handler.js

@@ -1,9 +0,0 @@
-// Создано: 2026-04-10
-// Демо-функция: возвращает текущее время сервера.
-// Юзер меняет код под себя и перебилдит через terraform apply.
-
-'use strict';
-
-module.exports.handler = function handler(event) {
-    return `Текущее время: ${new Date().toISOString()}`;
-};

examples/POSTGRES/code/calc-node/package.json

@@ -1,3 +0,0 @@
-{
-  "dependencies": {}
-}

examples/POSTGRES/code/calc-python/handler.py

@@ -1,105 +0,0 @@
-# Создано: 2026-04-10
-# Изменено: 2026-03-23 — упрощён до поля ввода выражения (демонстрация деплоя).
-# Принимает произвольное математическое выражение: "2+2*(3-1)", "(10/3)**2" и т.д.
-# GET → HTML страница с формой; POST с {expr} → вычисление через безопасный eval.
-# Безопасность eval: __builtins__=None, только math-функции в locals.
-
-import math
-
-_PAGE = """<!DOCTYPE html>
-<html lang="ru">
-<head>
-<meta charset="utf-8">
-<meta name="viewport" content="width=device-width, initial-scale=1">
-<title>Калькулятор — Python 3.11</title>
-<style>
-  body { font-family: monospace; background: #0f172a; color: #e2e8f0;
-         display: flex; justify-content: center; align-items: center; min-height: 100vh; margin: 0; }
-  .box { background: #1e293b; border-radius: 12px; padding: 32px; width: 420px; box-shadow: 0 8px 32px #0005; }
-  h2 { margin: 0 0 4px; font-size: 20px; color: #7dd3fc; }
-  .sub { color: #475569; font-size: 12px; margin-bottom: 24px; }
-  input { width: 100%; box-sizing: border-box; padding: 10px 14px; font-size: 18px; font-family: monospace;
-          background: #0f172a; border: 1px solid #334155; border-radius: 8px; color: #f1f5f9; outline: none; }
-  input:focus { border-color: #38bdf8; }
-  button { margin-top: 12px; width: 100%; padding: 12px; font-size: 16px; background: #0369a1;
-           color: #fff; border: none; border-radius: 8px; cursor: pointer; }
-  button:hover { background: #0284c7; }
-  button:disabled { background: #1e3a5f; color: #475569; cursor: default; }
-  .result { margin-top: 20px; padding: 14px; border-radius: 8px; font-size: 22px; text-align: center; display: none; }
-  .ok  { background: #064e3b; color: #6ee7b7; display: block; }
-  .err { background: #450a0a; color: #fca5a5; font-size: 14px; display: block; }
-</style>
-</head>
-<body>
-<div class="box">
-  <h2>Калькулятор</h2>
-  <div class="sub">Python 3.11 · runtime: sless</div>
-  <input id="expr" autofocus placeholder="например: 2 + 2 * (3 - 1)">
-  <button id="btn" onclick="calc()">Вычислить</button>
-  <div id="result" class="result"></div>
-</div>
-<script>
-  document.getElementById('expr').addEventListener('keydown', function(e) {
-    if (e.key === 'Enter') calc();
-  });
-  async function calc() {
-    const expr = document.getElementById('expr').value.trim();
-    if (!expr) return;
-    const btn = document.getElementById('btn');
-    const res = document.getElementById('result');
-    btn.disabled = true;
-    btn.textContent = '…';
-    try {
-      const r = await fetch('', {
-        method: 'POST',
-        headers: {'Content-Type': 'application/json'},
-        body: JSON.stringify({expr: expr})
-      });
-      const data = await r.json();
-      if (data.error) {
-        res.className = 'result err';
-        res.textContent = data.error;
-      } else {
-        res.className = 'result ok';
-        res.textContent = expr + ' = ' + data.result;
-      }
-    } catch(e) {
-      res.className = 'result err';
-      res.textContent = 'Ошибка сети: ' + e.message;
-    }
-    btn.disabled = false;
-    btn.textContent = 'Вычислить';
-  }
-</script>
-</body>
-</html>"""
-
-# Разрешённые math-функции в eval — без __builtins__ нет доступа к exec/open/etc.
-_MATH_LOCALS = {k: getattr(math, k) for k in dir(math) if not k.startswith('_')}
-
-
-def handler(event):
-    if event.get('_method') == 'POST':
-        expr = str(event.get('expr', '')).strip()
-        return _compute(expr)
-    # GET → HTML страница
-    return _PAGE
-
-
-def _compute(expr):
-    if not expr:
-        return {'error': 'Введите выражение'}
-    try:
-        result = eval(expr, {'__builtins__': None}, _MATH_LOCALS)  # noqa: S307
-        if not isinstance(result, (int, float)):
-            return {'error': 'Результат не является числом'}
-        return {'expr': expr, 'result': result}
-    except ZeroDivisionError:
-        return {'error': 'Деление на ноль'}
-    except Exception as exc:
-        return {'error': f'Ошибка: {exc}'}
-
-
-def _esc(s):
-    # Экранируем HTML-спецсимволы — безопасный вывод в атрибут и тело.
-    return s.replace('&', '&amp;').replace('<', '&lt;').replace('>', '&gt;').replace('"', '&quot;')

examples/POSTGRES/code/calc-python/requirements.txt

@@ -1 +0,0 @@
-# нет внешних зависимостей

examples/POSTGRES/functions.tf

@@ -1,36 +0,0 @@
-# Создано: 2026-04-10
-# functions.tf — sless_service ресурсы для примера POSTGRES.
-# Здесь: два калькуляторa — Python и Node.js.
-# sless_service = long-running Deployment + постоянный URL (в отличие от sless_function).
-
-# ─── Python-калькулятор ──────────────────────────────────────────────────────
-
-resource "sless_service" "calc_python" {
-  name       = "calc-python"
-  runtime    = "python3.11"
-  entrypoint = "handler.handler"
-  memory_mb   = 128
-  timeout_sec = 30
-  source_dir  = "${path.module}/code/calc-python"
-}
-
-output "calc_python_url" {
-  description = "URL Python-калькулятора"
-  value       = sless_service.calc_python.url
-}
-
-# ─── Node.js-калькулятор ─────────────────────────────────────────────────────
-
-resource "sless_service" "calc_node" {
-  name       = "calc-node"
-  runtime    = "nodejs20"
-  entrypoint = "handler.handler"
-  memory_mb   = 128
-  timeout_sec = 30
-  source_dir  = "${path.module}/code/calc-node"
-}
-
-output "calc_node_url" {
-  description = "URL Node.js-калькулятора"
-  value       = sless_service.calc_node.url
-}

examples/POSTGRES/main.tf

@@ -4,7 +4,7 @@ terraform {
   required_providers {
     nubes = {
       source  = "terra.k8c.ru/nubes/nubes"
-      version = "5.0.51"
+      version = "5.0.19"
     }
     sless = {
       source  = "terra.k8c.ru/naeel/sless"
@@ -52,7 +52,6 @@ variable "pg_password" {
 
 provider "nubes" {
   api_token    = var.api_token
-  log_level    = "debug"   # none | info | debug, default = "none"
   api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
 }
 

examples/README.md

@@ -1,56 +1,75 @@
-# sless — примеры
+# Примеры использования sless
 
-> ⚠️ **Тестовое окружение.** Все примеры работают с тестовым API Nubes и тестовым кластером sless. Не используйте в продакшне без предварительного согласования.
+## Обзор платформы
 
-**sless** — платформа для запуска serverless-функций на базе Kubernetes.  
-Разработчик загружает код, платформа собирает Docker-образ и разворачивает его в кластере.  
-Всё описывается декларативно через Terraform.
+**sless** — система управления serverless-функциями на базе Kubernetes. Разработчик загружает код функции, платформа собирает из него Docker-образ, разворачивает его в кластере и предоставляет HTTP-эндпоинт для вызова. Всё описывается декларативно через Terraform.
 
----
+### Основные ресурсы провайдера
 
-## Ресурсы Terraform-провайдера
-
-| Ресурс | Что делает |
+| Ресурс | Назначение |
 |---|---|
-| `sless_job` | Разовый запуск: выполняет код один раз и завершается (установка ПО, миграции и т.д.) |
-| `sless_service` | HTTP-сервис: всегда запущен, отвечает на запросы, имеет постоянный URL — _примеры появятся позднее_ |
+| `sless_service` | Long-running HTTP-сервис: всегда активен, отвечает на запросы. Имеет свой URL после деплоя. |
+| `sless_job` | Одноразовый запуск функции: собирает образ, выполняет код, завершается. Используется для миграций БД, batch-обработки и т.д. |
+
+Namespace функций вычисляется автоматически из JWT-токена: `sless-{sha256[:8]}`.
 
 ---
 
+## Требования
+
+- Terraform >= 1.3
+- JWT-токен для аутентификации в sless API
+- JWT-токен для Nubes Cloud API (если используются managed-ресурсы: PostgreSQL и т.д.)
+- Доступ к `https://sless.kube5s.ru`
+
 ## Конфигурация провайдера
 
 ```hcl
 provider "sless" {
   endpoint = "https://sless.kube5s.ru"
-  token    = var.api_token
+  token    = var.sless_token
+}
+
+provider "nubes_cloud" {
+  base_url = "https://deck-api-test.ngcloud.ru/api/v1"
+  token    = var.nubes_token
 }
 ```
 
-Токен задаётся в `terraform.tfvars` (файл в `.gitignore`, не попадает в git).
+> Токены задаются в `terraform.tfvars` — этот файл добавлен в `.gitignore`.
 
 ---
 
 ## Примеры
 
-### [`VM/`](VM/) — Виртуальная машина в Nubes vDC
+### `POSTGRES` — Serverless-функции с Managed PostgreSQL
 
-Создаёт vApp + Ubuntu 22.04 VM в облаке Nubes. После создания — автоматически устанавливает ПО (nginx, Docker, пакеты) через serverless-джобы (`sless_job`) по SSH.
+Полный пример: managed PostgreSQL + одноразовый init-job + 3 HTTP-сервиса (чтение/запись данных и информация о PG).
 
-> В этом примере используются только **разовые джобы** (`sless_job`). Примеры с HTTP-сервисами (`sless_service`) появятся позднее.
+Языки: Python 3.11, Node.js 20.
 
-**→ [Начать здесь](VM/README.md)**
+```bash
+cd POSTGRES
+terraform init
+terraform apply
+```
+
+Подробности: [POSTGRES/README.md](POSTGRES/README.md)
 
 ---
 
 ## Полезные команды
 
 ```bash
-# Посмотреть состояние ресурсов:
+# Посмотреть состояние задеплоенных ресурсов:
 terraform show
 
-# Повторно запустить установку ПО: увеличить install_run_id в terraform.tfvars, затем:
+# Принудительно пересобрать сервис (после изменения кода):
+terraform apply -replace=sless_service.<имя>
+
+# Повторно запустить job: увеличить run_id в .tf-файле, затем:
 terraform apply
 
-# Удалить все ресурсы:
+# Удалить все ресурсы примера:
 terraform destroy
 ```

examples/VM/README.md

@@ -1,208 +0,0 @@
-# Пример: Виртуальная машина (vApp + VM) в Nubes vDC
-
-> ⚠️ **Тестовое окружение.** Пример работает с тестовым API Nubes и тестовым кластером sless. Не использовать в продакшне без предварительного согласования.
-
-> В этом примере используются только **разовые джобы** (`sless_job`) — для установки ПО на ВМ. Примеры с HTTP-сервисами (`sless_service`) появятся позднее.
-
-Создаёт:
-- **vApp** — виртуальный каталог (контейнер для ВМ в VMware vDC)
-- **ВМ** — Ubuntu 22.04, 2 CPU / 2 GB RAM / 20 GB disk
-- **Serverless-джобы** — устанавливают ПО на ВМ по SSH после создания
-
----
-
-## Быстрый старт
-
-```bash
-cp terraform.tfvars.template terraform.tfvars
-# Заполни terraform.tfvars (инструкция ниже)
-terraform init
-terraform apply
-```
-
----
-
-## Шаг 1 — Получить данные из Личного Кабинета
-
-### API-токен
-
-> Личный Кабинет → правый верхний угол → **«Профиль»** → **«API-токены»** → **«Создать токен»**
-
-Скопируйте JWT-строку целиком (`eyJhbGciOiJS...`).  
-Один токен работает для обоих провайдеров — nubes (облако) и sless (serverless).
-
-### UUID сервисов (vdc_uid и nsxt_uid)
-
-> Личный Кабинет → **«Мои сервисы»** → нужный сервис → **«Параметры инстанса»** → поле UUID
-
-| Параметр | Что искать в ЛК |
-|---|---|
-| `vdc_uid` | Сервис **«Виртуальный датацентр (vDC)»** → UUID |
-| `nsxt_uid` | Сервис **«Сетевой шлюз периметра (Edge)»** → UUID |
-
-UUID выглядит так: `e3c9e4f1-24da-4992-a003-f8a2a803a5f0`
-
-> **Важно:** `vdc_uid` и `nsxt_uid` **не изменяются после первого `terraform apply`**.  
-> Менять их нельзя — сломается terraform state.
-
----
-
-## Шаг 2 — Сгенерировать SSH-ключ для ВМ
-
-Публичный ключ прописывается в ВМ при создании — это **единственный** способ зайти по SSH.
-
-```bash
-# Выполнить в папке examples/VM/
-ssh-keygen -t ed25519 -f ./vm_key -N "" -C "sless-demo-vm"
-```
-
-Создаст два файла: `vm_key` (приватный) и `vm_key.pub` (публичный).
-
----
-
-## Шаг 3 — Заполнить terraform.tfvars
-
-```bash
-cp terraform.tfvars.template terraform.tfvars
-```
-
-Открыть `terraform.tfvars` и заполнить:
-
-```hcl
-api_token     = "eyJhbGciOiJS..."                        # из ЛК (шаг 1)
-vm_public_key = "ssh-ed25519 AAAA..."                    # содержимое vm_key.pub (шаг 2)
-vdc_uid       = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"   # из ЛК (шаг 1)
-nsxt_uid      = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"   # из ЛК (шаг 1)
-```
-
-Остальные параметры (`install_packages`, `base_packages` и т.д.) можно менять в любое время.
-
----
-
-## Запуск
-
-```bash
-terraform init
-terraform apply
-```
-
-После успешного `apply` Terraform выведет:
-
-```
-Outputs:
-
-vm_id    = "..."
-vm_state = {
-  "externalIp" = "1.2.3.4"
-  ...
-}
-vapp_id  = "..."
-```
-
----
-
-## Подключение по SSH
-
-```bash
-ssh -i ./vm_key ubuntu@<externalIp из vm_state>
-```
-
-Логин всегда `ubuntu`.
-
----
-
-## Управление установкой ПО
-
-Установка выполняется через serverless-джобы — Terraform запускает k8s Job, который подключается к ВМ по SSH и устанавливает пакеты.
-
-### Флаги установки (в terraform.tfvars)
-
-| Переменная | Что делает | По умолчанию |
-|---|---|---|
-| `install_packages` | Устанавливает пакеты из `base_packages` | `true` |
-| `install_nginx` | Устанавливает nginx | `true` |
-| `install_docker` | Устанавливает Docker CE + docker-compose-plugin | `true` |
-
-### Как изменить список пакетов
-
-В `terraform.tfvars`:
-
-```hcl
-base_packages = ["jq", "htop", "curl", "git", "python3-pip"]
-```
-
-Любые стандартные apt-пакеты Ubuntu 22.04.  
-После изменения — увеличьте `install_run_id` и выполните `terraform apply`.
-
-### Как перезапустить установку
-
-sless_job — разовый джоб. При повторном `apply` Terraform не перезапускает его если ничего не изменилось.  
-Чтобы запустить все install-джобы заново — увеличьте `install_run_id` на 1:
-
-```hcl
-# было:
-install_run_id = 3
-# стало:
-install_run_id = 4
-```
-
-Затем `terraform apply`. Установка идемпотентна — повторное выполнение не ломает систему.
-
-### Как отключить отдельный компонент
-
-```hcl
-install_docker = false   # не устанавливать Docker
-```
-
-После `apply` ресурс `sless_job.install_docker` будет удалён из state.  
-Docker на уже созданной ВМ останется — Terraform не удаляет пакеты.
-
----
-
-## Удаление
-
-```bash
-terraform destroy
-```
-
-Порядок автоматический: сначала suspend → потом delete.  
-Параметр `suspend_on_destroy = true` решает это — без него удаление упадёт с ошибкой Nubes _«Услуга не остановлена»_.
-
----
-
-## Справочник параметров
-
-### Можно менять в любое время
-
-| Параметр | Файл | Эффект |
-|---|---|---|
-| `vm_cpu`, `vm_ram`, `vm_disk` | `vm.tf` | ВМ будет изменена |
-| `install_packages/nginx/docker` | `terraform.tfvars` | Джоб добавится или удалится |
-| `base_packages` | `terraform.tfvars` | Пакеты изменятся — увеличить `install_run_id` + apply |
-| `install_run_id` | `terraform.tfvars` | Перезапускает все install-джобы |
-
-### Нельзя менять после первого apply
-
-| Параметр | Файл | Причина |
-|---|---|---|
-| `vdc_uid`, `nsxt_uid` | `terraform.tfvars` | Идентифицируют сервисы в terraform state |
-| `resource_name`, `vapp_name` | `vapp.tf` | Уникальные имена ресурсов в Nubes |
-| `image_vm`, `user_login` | `vm.tf` | Неизменяемые параметры ВМ |
-| `vm_public_key` | `terraform.tfvars` | Прописывается в ВМ один раз при создании |
-
----
-
-## Файлы проекта
-
-| Файл | Назначение |
-|---|---|
-| `terraform.tfvars.template` | **Шаблон** — скопировать в `terraform.tfvars` и заполнить |
-| `terraform.tfvars` | Ваши значения (не в git — содержит секреты) |
-| `main.tf` | Провайдеры + переменные `api_token` и `vm_public_key` |
-| `variables.tf` | Все остальные переменные с описаниями |
-| `vapp.tf` | Ресурс vApp (контейнер ВМ) |
-| `vm.tf` | Ресурс ВМ (Ubuntu 22.04) |
-| `sless.tf` | Serverless-джобы для установки ПО |
-| `outputs.tf` | Вывод IP-адреса и ID ресурсов |
-| `vm_key` / `vm_key.pub` | SSH-ключ — **создаётся вами на Шаге 2**, в git не хранится |
-| `functions/` | Код Python-функций для install-джобов |

examples/VM/VM_TEST_README.md

@@ -1,106 +0,0 @@
-# VM Stress Test — Инструкция по запуску
-# 2026-03-30
-
-## ⛔⛔⛔ КРИТИЧЕСКИЕ ПРАВИЛА ⛔⛔⛔
-
-### ЗАПРЕЩЕНО (без исключений):
-- **НЕ РЕДАКТИРОВАТЬ** `terraform.tfvars` — там JWT-токен, потеря = катастрофа
-- **НЕ РЕДАКТИРОВАТЬ** `*.tf` файлы
-- **НЕ РЕДАКТИРОВАТЬ** `vm_stress_test.sh`
-- **НЕ ЗАПУСКАТЬ** `terraform` напрямую — только через скрипт
-- **НЕ СОЗДАВАТЬ** новые файлы в этой директории
-- **НЕ ДЕЛАТЬ** `sed`, `awk`, `cat >`, `tee` в terraform.tfvars
-
-### ПОЧЕМУ:
-Предыдущая версия скрипта содержала функцию `write_tfvars()` которая
-перезаписывала `terraform.tfvars`. В процессе перезаписи был потерян
-JWT-токен `api_token` (1200+ символов). Это привело к полному отказу
-terraform и потере рабочего состояния. Восстановление заняло час.
-
-### КАК РАБОТАЕТ НОВЫЙ СКРИПТ:
-Переменные переопределяются через `-var` в terraform CLI.
-Файл `terraform.tfvars` читается terraform автоматически,
-но **НИКОГДА не перезаписывается** скриптом.
-
-После каждой фазы проверяется md5sum terraform.tfvars.
-Если файл изменился — **АВАРИЙНАЯ ОСТАНОВКА** (exit code 99).
-
----
-
-## Запуск
-
-### На VM (naeel@5.172.178.213):
-
-```bash
-cd ~/terra/sless/examples/VM
-bash vm_stress_test.sh 2>&1 | tee /tmp/vm_stress_$(date +%Y%m%d_%H%M).log
-```
-
-### Быстрый прогон (без destroy/resurrect — фазы 7-9 пропускаются):
-
-```bash
-SKIP_DESTROY=1 bash vm_stress_test.sh 2>&1 | tee /tmp/vm_stress.log
-```
-
-### Количество stress-циклов (default: 2):
-
-```bash
-STRESS_CYCLES=3 bash vm_stress_test.sh 2>&1 | tee /tmp/vm_stress.log
-```
-
----
-
-## Анализ результатов
-
-### Быстрый обзор:
-```bash
-grep -E '\[(PASS|FAIL|SKIP)\]' /tmp/vm_stress.log
-```
-
-### Только ошибки:
-```bash
-grep '\[FAIL\]' /tmp/vm_stress.log
-```
-
-### Итоговая сводка — последние 20 строк лога:
-```bash
-tail -20 /tmp/vm_stress.log
-```
-
----
-
-## Фазы теста
-
-| # | Имя             | Что делает                                         |
-|---|-----------------|---------------------------------------------------|
-| 1 | BASELINE        | apply с полным набором (packages+nginx+docker)     |
-| 2 | IDEMPOTENT      | plan → "No changes" (проверка идемпотентности)     |
-| 3 | PARTIAL_DISABLE | отключить nginx + docker через -var                |
-| 4 | PARTIAL_ENABLE  | включить обратно nginx + docker                    |
-| 5 | REORDER_PACKAGES| изменить набор base_packages через -var            |
-| 6 | MANUAL_PURGE    | удалить пакеты с VM по SSH → переустановить        |
-| 7 | DESTROY         | terraform destroy → VM в suspend                   |
-| 8 | RESURRECT       | apply после destroy → VM просыпается               |
-| 9 | STRESS_CYCLES   | N циклов destroy/apply подряд                      |
-|10 | FINAL_SANITY    | финальная проверка VM + пакеты + plan              |
-
----
-
-## Текущее состояние (baseline)
-
-5 ресурсов в state:
-- `nubes_vapp.vapp`
-- `nubes_vc_vm_v3.vm`
-- `sless_job.install_packages[0]`
-- `sless_job.install_nginx[0]`
-- `sless_job.install_docker[0]`
-
----
-
-## Exit codes
-
-| Code | Значение                                    |
-|------|---------------------------------------------|
-| 0    | Все тесты PASS                              |
-| 1    | Есть FAIL (см. лог)                         |
-| 99   | terraform.tfvars был изменён — АВАРИЙНЫЙ СТОП |

examples/VM/functions/install-docker/handler.py

@@ -1,158 +0,0 @@
-# 2026-03-29 — handler.py: установка Docker CE на ВМ по SSH.
-# sless_job runtime: python3.11, entrypoint: handler.install
-#
-# Метод установки: официальный Docker apt-репозиторий (best practices).
-# НЕ используется curl | sh — небезопасно для продакшена.
-#
-# event_json:
-#   compose: true/false  — ставить ли docker-compose-plugin (default: true)
-#
-# env_vars:
-#   VM_IP:    внешний IP ВМ
-#   SSH_USER: логин (ubuntu)
-#   SSH_KEY:  содержимое приватного SSH-ключа (PEM)
-
-import os, io, time
-import paramiko
-
-
-def _load_key(content):
-    for cls in (paramiko.Ed25519Key, paramiko.RSAKey, paramiko.ECDSAKey):
-        try:
-            return cls.from_private_key(io.StringIO(content))
-        except Exception:
-            pass
-    raise ValueError("Неподдерживаемый тип SSH-ключа")
-
-
-def _ssh_connect(retries=5, delay=10):
-    key = _load_key(os.environ["SSH_KEY"])
-    client = paramiko.SSHClient()
-    client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
-    last_err = None
-    for attempt in range(retries):
-        try:
-            client.connect(
-                hostname=os.environ["VM_IP"],
-                username=os.environ["SSH_USER"],
-                pkey=key,
-                timeout=15,
-            )
-            return client
-        except Exception as e:
-            last_err = e
-            if attempt < retries - 1:
-                time.sleep(delay)
-    raise RuntimeError(f"SSH не удалось после {retries} попыток: {last_err}")
-
-
-def _run(client, cmd, timeout=120, check=True):
-    _, stdout, stderr = client.exec_command(cmd, timeout=timeout)
-    code = stdout.channel.recv_exit_status()
-    out = stdout.read().decode(errors="replace").strip()
-    err = stderr.read().decode(errors="replace").strip()
-    if check and code != 0:
-        raise RuntimeError(f"Ошибка (exit {code}):\n{cmd}\nstderr: {err}")
-    return code, out, err
-
-
-def _wait_apt_lock(client, attempts=20, delay=10):
-    """Ждать завершения cloud-init и убить авто-обновления. Ubuntu 22.04+."""
-    # Шаг 1: Ждём завершения cloud-init — он держит apt при первом старте VM
-    _run(client, "timeout 300 sudo cloud-init status --wait 2>/dev/null; true", check=False, timeout=310)
-    # Шаг 2: Mask (не просто disable) — systemd не сможет перезапустить
-    _run(client, "sudo systemctl mask unattended-upgrades apt-daily.service apt-daily-upgrade.service apt-daily.timer apt-daily-upgrade.timer 2>/dev/null; true", check=False)
-    _run(client, "sudo systemctl stop unattended-upgrades apt-daily.service apt-daily-upgrade.service 2>/dev/null; true", check=False)
-    # Шаг 3: Добить оставшиеся apt/dpkg процессы
-    _run(client, "sudo pkill -9 -x unattended-upgrades apt-get apt dpkg 2>/dev/null; true", check=False)
-    _run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
-    # Шаг 4: Убрать стейл-локи и починить dpkg
-    _run(client, "sudo rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock /var/lib/apt/lists/lock 2>/dev/null; true", check=False)
-    _run(client, "sudo dpkg --configure -a 2>/dev/null; true", check=False)
-    time.sleep(3)
-
-    locks = ["/var/lib/dpkg/lock-frontend", "/var/lib/dpkg/lock", "/var/lib/apt/lists/lock"]
-    for i in range(attempts):
-        all_free = all(
-            _run(client, f"sudo flock -n {lock} true 2>/dev/null", check=False)[0] == 0
-            for lock in locks
-        )
-        if all_free:
-            return
-        _run(client, "sudo pkill -9 -x apt-get apt dpkg 2>/dev/null; true", check=False)
-        _run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
-        if i < attempts - 1:
-            time.sleep(delay)
-    raise RuntimeError("apt lock занят слишком долго — проверьте процессы на ВМ")
-
-
-# Команды установки Docker CE через официальный apt-репозиторий.
-# Источник: https://docs.docker.com/engine/install/ubuntu/
-_DOCKER_INSTALL_CMDS = [
-    # Зависимости для добавления внешнего репозитория
-    "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 install -y -qq ca-certificates curl gnupg",
-    # Директория для ключей
-    "sudo install -m 0755 -d /etc/apt/keyrings",
-    # GPG-ключ Docker
-    "curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor --batch --yes -o /etc/apt/keyrings/docker.gpg",
-    "sudo chmod a+r /etc/apt/keyrings/docker.gpg",
-    # Docker apt-репозиторий
-    (
-        'echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] '
-        'https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" '
-        "| sudo tee /etc/apt/sources.list.d/docker.list > /dev/null"
-    ),
-    # Обновить индекс с новым репо
-    "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 update -qq",
-    # Установить Docker CE
-    "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 install -y -qq docker-ce docker-ce-cli containerd.io",
-]
-
-
-def install(event):
-    """Установить Docker CE. Если уже установлен — вернуть версию."""
-    install_compose = event.get("compose", True)
-
-    client = _ssh_connect()
-    try:
-        # Проверить: уже установлен?
-        code, ver_out, _ = _run(client, "docker --version 2>&1", check=False)
-        if code == 0 and "Docker version" in ver_out:
-            _, compose_out, _ = _run(client, "docker compose version 2>&1", check=False)
-            return {
-                "status": "already_installed",
-                "docker_version": ver_out,
-                "compose_version": compose_out if "Docker Compose" in compose_out else None,
-            }
-
-        _wait_apt_lock(client)
-
-        for cmd in _DOCKER_INSTALL_CMDS:
-            _run(client, cmd, timeout=180)
-
-        if install_compose:
-            _run(
-                client,
-                "sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq docker-compose-plugin",
-                timeout=120,
-            )
-
-        # Добавить пользователя в группу docker (чтобы запускать без sudo)
-        ssh_user = os.environ["SSH_USER"]
-        _run(client, f"sudo usermod -aG docker {ssh_user}", check=False)
-
-        # Проверка: запустить hello-world
-        # Используем sudo т.к. usermod не применится до переподключения
-        _run(client, "sudo docker run --rm hello-world", timeout=120)
-
-        _, ver_out, _ = _run(client, "docker --version", check=False)
-        _, compose_out, _ = _run(client, "docker compose version 2>&1", check=False)
-
-        return {
-            "status": "ok",
-            "docker_version": ver_out,
-            "compose_version": compose_out if "Docker Compose" in compose_out else None,
-            "note": f"user '{ssh_user}' added to docker group (reconnect to use without sudo)",
-        }
-    finally:
-        client.close()

examples/VM/functions/install-docker/requirements.txt

@@ -1,2 +0,0 @@
-paramiko
-# v6

examples/VM/functions/install-nginx/handler.py

@@ -1,129 +0,0 @@
-# 2026-03-29 — handler.py: установка nginx на ВМ по SSH.
-# sless_job runtime: python3.11, entrypoint: handler.install
-#
-# event_json: {} (параметров нет — nginx ставится с дефолтной конфигурацией)
-#
-# env_vars:
-#   VM_IP:    внешний IP ВМ
-#   SSH_USER: логин (ubuntu)
-#   SSH_KEY:  содержимое приватного SSH-ключа (PEM)
-
-import os, io, time
-import paramiko
-
-
-def _load_key(content):
-    for cls in (paramiko.Ed25519Key, paramiko.RSAKey, paramiko.ECDSAKey):
-        try:
-            return cls.from_private_key(io.StringIO(content))
-        except Exception:
-            pass
-    raise ValueError("Неподдерживаемый тип SSH-ключа")
-
-
-def _ssh_connect(retries=5, delay=10):
-    key = _load_key(os.environ["SSH_KEY"])
-    client = paramiko.SSHClient()
-    client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
-    last_err = None
-    for attempt in range(retries):
-        try:
-            client.connect(
-                hostname=os.environ["VM_IP"],
-                username=os.environ["SSH_USER"],
-                pkey=key,
-                timeout=15,
-            )
-            return client
-        except Exception as e:
-            last_err = e
-            if attempt < retries - 1:
-                time.sleep(delay)
-    raise RuntimeError(f"SSH не удалось после {retries} попыток: {last_err}")
-
-
-def _run(client, cmd, timeout=120, check=True):
-    _, stdout, stderr = client.exec_command(cmd, timeout=timeout)
-    code = stdout.channel.recv_exit_status()
-    out = stdout.read().decode(errors="replace").strip()
-    err = stderr.read().decode(errors="replace").strip()
-    if check and code != 0:
-        raise RuntimeError(f"Ошибка (exit {code}):\n{cmd}\nstderr: {err}")
-    return code, out, err
-
-
-def _wait_apt_lock(client, attempts=20, delay=10):
-    """Ждать завершения cloud-init и убить авто-обновления. Ubuntu 22.04+."""
-    # Шаг 1: Ждём завершения cloud-init — он держит apt при первом старте VM
-    _run(client, "timeout 300 sudo cloud-init status --wait 2>/dev/null; true", check=False, timeout=310)
-    # Шаг 2: Mask (не просто disable) — systemd не сможет перезапустить
-    _run(client, "sudo systemctl mask unattended-upgrades apt-daily.service apt-daily-upgrade.service apt-daily.timer apt-daily-upgrade.timer 2>/dev/null; true", check=False)
-    _run(client, "sudo systemctl stop unattended-upgrades apt-daily.service apt-daily-upgrade.service 2>/dev/null; true", check=False)
-    # Шаг 3: Добить оставшиеся apt/dpkg процессы
-    _run(client, "sudo pkill -9 -x unattended-upgrades apt-get apt dpkg 2>/dev/null; true", check=False)
-    _run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
-    # Шаг 4: Убрать стейл-локи и починить dpkg
-    _run(client, "sudo rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock /var/lib/apt/lists/lock 2>/dev/null; true", check=False)
-    _run(client, "sudo dpkg --configure -a 2>/dev/null; true", check=False)
-    time.sleep(3)
-
-    locks = ["/var/lib/dpkg/lock-frontend", "/var/lib/dpkg/lock", "/var/lib/apt/lists/lock"]
-    for i in range(attempts):
-        all_free = all(
-            _run(client, f"sudo flock -n {lock} true 2>/dev/null", check=False)[0] == 0
-            for lock in locks
-        )
-        if all_free:
-            return
-        _run(client, "sudo pkill -9 -x apt-get apt dpkg 2>/dev/null; true", check=False)
-        _run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
-        if i < attempts - 1:
-            time.sleep(delay)
-    raise RuntimeError("apt lock занят слишком долго — проверьте процессы на ВМ")
-
-
-def install(event):
-    """Установить nginx. Если уже установлен — проверить что запущен."""
-    client = _ssh_connect()
-    try:
-        # Проверить: уже установлен?
-        code, ver_out, _ = _run(client, "nginx -v 2>&1", check=False)
-        already_installed = "nginx version" in ver_out
-
-        if already_installed:
-            # Убедиться что сервис запущен
-            _run(client, "sudo systemctl start nginx", check=False)
-            version = ver_out.replace("nginx version: nginx/", "").strip()
-            _, http_code, _ = _run(
-                client, "curl -s -o /dev/null -w '%{http_code}' http://localhost", check=False
-            )
-            return {
-                "status": "already_installed",
-                "version": version,
-                "http_check": http_code,
-            }
-
-        _wait_apt_lock(client)
-        _run(client, "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 update -qq", timeout=420)
-        _run(
-            client,
-            "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 install -y -qq nginx",
-            timeout=300,
-        )
-        _run(client, "sudo systemctl enable nginx")
-        _run(client, "sudo systemctl start nginx")
-
-        # Проверить HTTP-ответ на localhost
-        _, http_code, _ = _run(
-            client, "curl -s -o /dev/null -w '%{http_code}' http://localhost", check=False
-        )
-        _, ver_out, _ = _run(client, "nginx -v 2>&1", check=False)
-        version = ver_out.replace("nginx version: nginx/", "").strip()
-
-        return {
-            "status": "ok",
-            "version": version,
-            "http_check": http_code,
-        }
-    finally:
-        client.close()

examples/VM/functions/install-nginx/requirements.txt

@@ -1,2 +0,0 @@
-paramiko
-# v6

examples/VM/functions/install-packages/handler.py

@@ -1,133 +0,0 @@
-# 2026-03-29 — handler.py: установка apt-пакетов на ВМ по SSH.
-# sless_job runtime: python3.11, entrypoint: handler.install
-#
-# event_json:
-#   packages: ["git", "curl", ...]  — список пакетов (обязательно)
-#   update:   true/false            — apt-get update перед install (default: true)
-#
-# env_vars:
-#   VM_IP:    внешний IP ВМ
-#   SSH_USER: логин (ubuntu)
-#   SSH_KEY:  содержимое приватного SSH-ключа (PEM)
-
-import os, io, time
-import paramiko
-
-
-def _load_key(content):
-    """Загрузить SSH-ключ (Ed25519 / RSA / ECDSA)."""
-    for cls in (paramiko.Ed25519Key, paramiko.RSAKey, paramiko.ECDSAKey):
-        try:
-            return cls.from_private_key(io.StringIO(content))
-        except Exception:
-            pass
-    raise ValueError("Неподдерживаемый тип SSH-ключа")
-
-
-def _ssh_connect(retries=5, delay=10):
-    """Подключение к ВМ с retry — ВМ может ещё загружаться."""
-    key = _load_key(os.environ["SSH_KEY"])
-    client = paramiko.SSHClient()
-    client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
-    last_err = None
-    for attempt in range(retries):
-        try:
-            client.connect(
-                hostname=os.environ["VM_IP"],
-                username=os.environ["SSH_USER"],
-                pkey=key,
-                timeout=15,
-            )
-            return client
-        except Exception as e:
-            last_err = e
-            if attempt < retries - 1:
-                time.sleep(delay)
-    raise RuntimeError(f"SSH не удалось после {retries} попыток: {last_err}")
-
-
-def _run(client, cmd, timeout=120, check=True):
-    """Выполнить команду, вернуть (exit_code, stdout, stderr)."""
-    _, stdout, stderr = client.exec_command(cmd, timeout=timeout)
-    code = stdout.channel.recv_exit_status()
-    out = stdout.read().decode(errors="replace").strip()
-    err = stderr.read().decode(errors="replace").strip()
-    if check and code != 0:
-        raise RuntimeError(f"Ошибка (exit {code}):\n{cmd}\nstderr: {err}")
-    return code, out, err
-
-
-def _wait_apt_lock(client, attempts=20, delay=10):
-    """Ждать завершения cloud-init и убить авто-обновления. Ubuntu 22.04+."""
-    # Шаг 1: Ждём завершения cloud-init — он держит apt при первом старте VM
-    _run(client, "timeout 300 sudo cloud-init status --wait 2>/dev/null; true", check=False, timeout=310)
-    # Шаг 2: Mask (не просто disable) — systemd не сможет перезапустить
-    _run(client, "sudo systemctl mask unattended-upgrades apt-daily.service apt-daily-upgrade.service apt-daily.timer apt-daily-upgrade.timer 2>/dev/null; true", check=False)
-    _run(client, "sudo systemctl stop unattended-upgrades apt-daily.service apt-daily-upgrade.service 2>/dev/null; true", check=False)
-    # Шаг 3: Добить оставшиеся apt/dpkg процессы
-    _run(client, "sudo pkill -9 -x unattended-upgrades apt-get apt dpkg 2>/dev/null; true", check=False)
-    _run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
-    # Шаг 4: Убрать стейл-локи и починить dpkg
-    _run(client, "sudo rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock /var/lib/apt/lists/lock 2>/dev/null; true", check=False)
-    _run(client, "sudo dpkg --configure -a 2>/dev/null; true", check=False)
-    time.sleep(3)
-
-    locks = [
-        "/var/lib/dpkg/lock-frontend",
-        "/var/lib/dpkg/lock",
-        "/var/lib/apt/lists/lock",
-    ]
-    for i in range(attempts):
-        all_free = all(
-            _run(client, f"sudo flock -n {lock} true 2>/dev/null", check=False)[0] == 0
-            for lock in locks
-        )
-        if all_free:
-            return
-        # Повторить убийство процессов удерживающих lock
-        _run(client, "sudo pkill -9 -x apt-get apt dpkg 2>/dev/null; true", check=False)
-        _run(client, "sudo kill -9 $(sudo lsof -t /var/lib/dpkg/lock-frontend 2>/dev/null) 2>/dev/null; true", check=False)
-        if i < attempts - 1:
-            time.sleep(delay)
-    raise RuntimeError("apt lock занят слишком долго — проверьте процессы на ВМ")
-
-
-def install(event):
-    """Установить apt-пакеты. Идемпотентно — повторный запуск безопасен."""
-    packages = event.get("packages", [])
-    if not packages:
-        return {"status": "skipped", "reason": "packages list is empty"}
-
-    do_update = event.get("update", True)
-
-    client = _ssh_connect()
-    try:
-        _wait_apt_lock(client)
-
-        if do_update:
-            _run(client, "sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 update -qq", timeout=420)
-
-        pkg_str = " ".join(packages)
-        _run(
-            client,
-            f"sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=600 install -y -qq {pkg_str}",
-            timeout=300,
-        )
-
-        # Проверить что установилось
-        installed, missing = [], []
-        for pkg in packages:
-            code, _, _ = _run(
-                client,
-                f"dpkg -l {pkg} 2>/dev/null | grep -q '^ii'",
-                check=False,
-            )
-            (installed if code == 0 else missing).append(pkg)
-
-        return {
-            "status": "ok" if not missing else "partial",
-            "installed": installed,
-            "missing": missing,
-        }
-    finally:
-        client.close()

examples/VM/functions/install-packages/requirements.txt

@@ -1,2 +0,0 @@
-paramiko
-# v6

examples/VM/main.tf

@@ -1,43 +0,0 @@
-// 2026-03-25 — main.tf для примера с vApp + ВМ (Виртуальный датацентр Nubes).
-// Провайдер nubes. Sless-провайдер не нужен — пример чисто инфраструктурный.
-
-terraform {
-  required_providers {
-    nubes = {
-      source  = "terra.k8c.ru/nubes/nubes"
-      version = "5.0.51"
-    }
-    sless = {
-      source  = "terra.k8c.ru/naeel/sless"
-      version = "~> 0.1"
-    }
-  }
-}
-
-# ------------------------------------------------------------------
-# Переменные
-# ------------------------------------------------------------------
-
-variable "vm_public_key" {
-  type        = string
-  sensitive   = true
-  description = "Публичный SSH-ключ для ВМ. Приватный ключ: ~/terra/sless/examples/VM/vm_key"
-}
-
-variable "api_token" {
-  type        = string
-  sensitive   = true
-  description = "Nubes API token"
-}
-
-# ------------------------------------------------------------------
-# Провайдер
-# ------------------------------------------------------------------
-
-# API Dashboard (для Terraform-провайдеров): https://deck-api-test.ngcloud.ru/api/v1/index.cfm
-# UI облака (только браузер):               https://deck-test.ngcloud.ru/
-provider "nubes" {
-  api_token    = var.api_token
-  api_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
-  log_level    = "debug"   # none | info | debug, default = "none"
-}

examples/VM/outputs.tf

@@ -1,18 +0,0 @@
-# 2026-03-29 — outputs.tf: результаты установки ПО на ВМ.
-# phase: Pending / Building / Running / Succeeded / Failed
-# message: JSON с деталями (что установлено) или traceback при ошибке
-
-output "install_packages_result" {
-  description = "Результат установки базовых пакетов"
-  value       = var.install_packages ? sless_job.install_packages[0].message : "skipped"
-}
-
-output "install_nginx_result" {
-  description = "Результат установки nginx"
-  value       = var.install_nginx ? sless_job.install_nginx[0].message : "skipped"
-}
-
-output "install_docker_result" {
-  description = "Результат установки Docker"
-  value       = var.install_docker ? sless_job.install_docker[0].message : "skipped"
-}

examples/VM/sless.tf

@@ -1,105 +0,0 @@
-# 2026-03-29 — sless.tf: провайдер sless и sless_job ресурсы для установки ПО на ВМ.
-#
-# Схема работы:
-#   1. terraform apply создаёт FunctionJob CR в k8s
-#   2. Провайдер загружает код из source_dir в S3
-#   3. Оператор собирает Docker-образ (kaniko) и запускает Job
-#   4. Job подключается к ВМ по SSH и устанавливает ПО
-#   5. terraform apply завершается: outputs содержат статус каждого шага
-#
-# Для повторного запуска: увеличь install_run_id в terraform.tfvars → terraform apply
-
-# ---------------------------------------------------------------------------
-# Провайдер
-# ---------------------------------------------------------------------------
-
-provider "sless" {
-  endpoint       = "https://sless.kube5s.ru"
-  token          = var.api_token # тот же JWT что и в provider "nubes"
-  nubes_endpoint = "https://deck-api-test.ngcloud.ru/api/v1/index.cfm"
-}
-
-# ---------------------------------------------------------------------------
-# Общие locals: SSH-параметры для подключения к ВМ
-# ---------------------------------------------------------------------------
-
-locals {
-  vm_ip = nubes_vc_vm_v3.vm.state_out_flat["externalConnect"]
-
-  ssh_env = {
-    VM_IP    = local.vm_ip
-    SSH_USER = "ubuntu"
-    SSH_KEY = file("${path.module}/vm_key")  # приватный ключ, созданный на шаге 2 (не хранится в git)
-  }
-}
-
-# ---------------------------------------------------------------------------
-# Job 1: базовые пакеты (jq, pip3 и др.)
-# ---------------------------------------------------------------------------
-
-resource "sless_job" "install_packages" {
-  count = var.install_packages ? 1 : 0
-
-  name       = "vm-install-packages"
-  runtime    = "python3.11"
-  entrypoint = "handler.install"
-  source_dir = "${path.module}/functions/install-packages"
-  memory_mb  = 128
-
-  env_vars = local.ssh_env
-  event_json = jsonencode({
-    packages = var.base_packages
-    update   = true
-  })
-
-  run_id           = var.install_run_id
-  wait_timeout_sec = 600
-
-  depends_on = [nubes_vc_vm_v3.vm]
-}
-
-# ---------------------------------------------------------------------------
-# Job 2: nginx
-# ---------------------------------------------------------------------------
-
-resource "sless_job" "install_nginx" {
-  count = var.install_nginx ? 1 : 0
-
-  name       = "vm-install-nginx"
-  runtime    = "python3.11"
-  entrypoint = "handler.install"
-  source_dir = "${path.module}/functions/install-nginx"
-  memory_mb  = 128
-
-  env_vars   = local.ssh_env
-  event_json = jsonencode({})
-
-  run_id           = var.install_run_id
-  wait_timeout_sec = 600
-
-  depends_on = [nubes_vc_vm_v3.vm, sless_job.install_packages]
-}
-
-# ---------------------------------------------------------------------------
-# Job 3: Docker CE
-# ---------------------------------------------------------------------------
-
-resource "sless_job" "install_docker" {
-  count = var.install_docker ? 1 : 0
-
-  name       = "vm-install-docker"
-  runtime    = "python3.11"
-  entrypoint = "handler.install"
-  source_dir = "${path.module}/functions/install-docker"
-  memory_mb  = 128
-
-  env_vars = local.ssh_env
-  event_json = jsonencode({
-    compose = true
-  })
-
-  run_id           = var.install_run_id
-  wait_timeout_sec = 900
-
-  depends_on = [nubes_vc_vm_v3.vm, sless_job.install_packages, sless_job.install_nginx]
-}

examples/VM/terraform.tfvars.template

@@ -1,112 +0,0 @@
-# =============================================================================
-# terraform.tfvars.template — шаблон конфигурации примера «ВМ в Nubes vDC»
-# =============================================================================
-#
-# Скопируйте этот файл в terraform.tfvars и заполните все значения:
-#
-#   cp terraform.tfvars.template terraform.tfvars
-#
-# terraform.tfvars НЕ коммитится в git (защищён .gitignore) —
-# он содержит секретные данные (API-токен, SSH-ключ).
-# =============================================================================
-
-
-# =============================================================================
-# 1. API-ТОКЕН
-# =============================================================================
-#
-# Один токен для обоих провайдеров: nubes (облако) и sless (serverless).
-#
-# Где взять:
-#   Личный Кабинет Nubes → правый верхний угол → «Профиль» → «API-токены»
-#   → кнопка «Создать токен» → скопируйте JWT-строку целиком.
-#
-# Токен выглядит так: eyJhbGciOiJS...длинная строка...
-# Вставьте в кавычки целиком, не разбивая на строки.
-#
-api_token = "ВСТАВИТЬ_API_ТОКЕН"
-
-
-# =============================================================================
-# 2. SSH-КЛЮЧ ДЛЯ ВМ
-# =============================================================================
-#
-# Публичный ключ прописывается в ВМ при создании.
-# Приватный ключ нужен для SSH-подключения к ВМ.
-#
-# Как сгенерировать:
-#   ssh-keygen -t ed25519 -f ./vm_key -N "" -C "sless-demo-vm"
-#   # Создаст два файла: vm_key (приватный) и vm_key.pub (публичный)
-#
-# vm_key.pub уже есть в папке — скопируйте его содержимое сюда.
-# Строка выглядит так: ssh-ed25519 AAAA... имя-ключа
-#
-vm_public_key = "ВСТАВИТЬ_ПУБЛИЧНЫЙ_SSH_КЛЮЧ"
-
-
-# =============================================================================
-# 3. UUID СЕРВИСОВ NUBES (вdc_uid и nsxt_uid)
-# =============================================================================
-#
-# Где взять:
-#   Личный Кабинет → «Мои сервисы» → найдите нужный сервис → раздел
-#   «Параметры инстанса» или «Технические параметры» → UUID.
-#
-#   vdc_uid  — это UUID услуги «Виртуальный датацентр (vDC)»
-#              Пример раздела ЛК: Мои сервисы → vDC → [ваш vDC] → UUID
-#
-#   nsxt_uid — это UUID услуги «Сетевой шлюз периметра (Edge)»
-#              Пример раздела ЛК: Мои сервисы → Edge → [ваш Edge] → UUID
-#
-# Формат: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  (UUID v4)
-#
-# ВАЖНО: эти значения не изменяются после создания vApp.
-# После первого terraform apply менять их нельзя — сломает state.
-#
-vdc_uid  = "ВСТАВИТЬ_UUID_VDC"
-nsxt_uid = "ВСТАВИТЬ_UUID_NSXT"
-
-
-# =============================================================================
-# 4. ФЛАГИ УСТАНОВКИ ПО НА ВМ
-# =============================================================================
-#
-# Что устанавливать при terraform apply.
-# Установка выполняется через serverless-джобы (sless_job) по SSH на ВМ.
-# Каждый флаг — отдельный джоб, они выполняются независимо.
-#
-# true  = установить
-# false = не устанавливать (ресурс не создаётся вовсе)
-#
-install_packages = true   # базовые apt-пакеты из списка base_packages ниже
-install_nginx    = true   # nginx (веб-сервер)
-install_docker   = true   # Docker CE + docker-compose-plugin
-
-
-# =============================================================================
-# 5. СПИСОК БАЗОВЫХ ПАКЕТОВ
-# =============================================================================
-#
-# Эти пакеты устанавливаются когда install_packages = true.
-# Любые стандартные apt-пакеты Ubuntu 22.04.
-#
-# Как изменить список:
-#   - Добавьте пакет: base_packages = ["jq", "htop", "curl", "git"]
-#   - Удалите пакет: уберите его из списка
-#   - После изменения: увеличьте install_run_id (см. ниже) и terraform apply
-#
-base_packages = ["jq", "python3-pip", "htop", "unzip"]
-
-
-# =============================================================================
-# 6. RUN_ID — триггер повторного запуска джобов
-# =============================================================================
-#
-# sless_job — это разовые джобы (k8s Job). Terraform не перезапускает их
-# автоматически если код не изменился. Чтобы запустить ВСЕ install-джобы
-# заново (например, после изменения base_packages) — увеличьте это число на 1
-# и выполните terraform apply.
-#
-# Например: было install_run_id = 3 → стало install_run_id = 4 → apply
-#
-install_run_id = 1

examples/VM/vapp.tf

@@ -1,28 +0,0 @@
-// 2026-03-25 — vapp.tf: виртуальный каталог ВМ (vApp) в Nubes vDC.
-// nubes_vapp — контейнер для ВМ внутри Виртуального датацентра.
-// Обязательные поля: vdc_uid, nsxt_uid, vapp_name, resource_name.
-
-resource "nubes_vapp" "vapp" {
-  resource_name = "vm-sless-vapp"
-  vapp_name     = "vapp-sless"                # Уникальное в рамках организации. Не изменяется после создания.
-  vdc_uid       = var.vdc_uid                 # UUID Услуги «Виртуальный датацентр (vDC)». В terraform.tfvars.
-  nsxt_uid      = var.nsxt_uid                # UUID Услуги «Сетевой шлюз периметра (Edge)». В terraform.tfvars.
-
-  adopt_existing_on_create = true
-  operation_timeout        = "15m"
-
-  # ВАЖНО: delete без предварительного suspend завершается ошибкой
-  # "Невозможно выполнить операцию удаления услуги. Услуга не остановлена"
-  # suspend_on_destroy гарантирует правильный порядок: suspend → delete.
-  suspend_on_destroy = true
-}
-
-output "vapp_id" {
-  value       = nubes_vapp.vapp.id
-  description = "ID созданного vApp (используется как vapp_uid при создании ВМ)"
-}
-
-output "vapp_state" {
-  value       = nubes_vapp.vapp.state_out_flat
-  description = "Плоский state vApp — адреса, статусы сети и т.д."
-}

examples/VM/variables.tf

@@ -1,51 +0,0 @@
-# 2026-03-29 — variables.tf: переменные для sless и установки ПО на ВМ.
-# Переменные nubes (api_token, vm_public_key) остаются в main.tf.
-# sless использует тот же api_token — отдельной переменной не нужно.
-
-# ---- Флаги: что устанавливать на ВМ --------------------------------------
-
-variable "install_packages" {
-  type        = bool
-  default     = true
-  description = "Установить базовые apt-пакеты (jq и др.)"
-}
-
-variable "install_nginx" {
-  type        = bool
-  default     = false
-  description = "Установить nginx"
-}
-
-variable "install_docker" {
-  type        = bool
-  default     = false
-  description = "Установить Docker CE + docker-compose-plugin"
-}
-
-# ---- Параметры ------------------------------------------------------------
-
-variable "base_packages" {
-  type        = list(string)
-  default     = ["jq", "python3-pip", "htop", "unzip"]
-  description = "Список apt-пакетов для install-packages"
-}
-
-variable "install_run_id" {
-  type        = number
-  default     = 1
-  description = "Увеличь на 1 чтобы запустить все install-джобы заново"
-}
-
-# ---- Идентификаторы сервисов Nubes ----------------------------------------
-# Берутся из Личного Кабинета → «Мои сервисы» → нужный сервис → параметры инстанса.
-# Не изменяются после создания vApp.
-
-variable "vdc_uid" {
-  type        = string
-  description = "UUID услуги «Виртуальный датацентр (vDC)». Личный Кабинет → Мои сервисы → vDC → UUID."
-}
-
-variable "nsxt_uid" {
-  type        = string
-  description = "UUID услуги «Сетевой шлюз периметра (Edge / NSX-T)». Личный Кабинет → Мои сервисы → Edge → UUID."
-}

examples/VM/vm.tf

@@ -1,37 +0,0 @@
-// 2026-03-25 — vm.tf: виртуальная машина (nubes_vc_vm_v3) внутри vApp.
-// Зависит от nubes_vapp.vapp — создаётся после vApp.
-// image_vm, vapp_uid, user_public_key не изменяются после создания.
-
-resource "nubes_vc_vm_v3" "vm" {
-  resource_name = "vm-sless-1"
-  vm_name       = "web02" # Имя ВМ в Nubes vCD. Не изменяется после создания.
-  # Определяет имя NSX-T IP Set: {vapp_name}-{vm_name}
-
-  vapp_uid = nubes_vapp.vapp.id # ссылка на vApp. Не изменяется после создания.
-  image_vm = "Ubuntu_22-20G"    # Не изменяется после создания.
-  #   image_vm      = "Ubuntu 22.04 LTS"              # Не изменяется после создания.
-  ip_space_name = "internet-ipv4-v1"
-
-  user_login      = "ubuntu"
-  user_public_key = var.vm_public_key # задаётся в terraform.tfvars
-
-  vm_cpu  = 2
-  vm_ram  = 2  # GB
-  vm_disk = 20 # GB
-
-  adopt_existing_on_create = true
-  operation_timeout        = "15m"
-
-  # delete без предварительного suspend завершается ошибкой (аналогично vApp).
-  suspend_on_destroy = true
-}
-
-output "vm_id" {
-  value       = nubes_vc_vm_v3.vm.id
-  description = "ID созданной ВМ"
-}
-
-output "vm_state" {
-  value       = nubes_vc_vm_v3.vm.state_out_flat
-  description = "Плоский state ВМ — IP-адреса, статус и т.д."
-}

examples/VM/vm_stress_test.sh

@@ -1,931 +0,0 @@
-#!/usr/bin/env bash
-# 2026-03-30 — vm_stress_test.sh (v2 — READ-ONLY)
-# Автономный READ-ONLY stress/chaos тест для examples/VM.
-#
-# ⛔⛔⛔ КРИТИЧЕСКОЕ ПРАВИЛО — ДЛЯ AI-АГЕНТОВ И ЛЮДЕЙ ⛔⛔⛔
-#
-# Этот скрипт НИКОГДА НЕ МОДИФИЦИРУЕТ terraform.tfvars и НИКАКИЕ ДРУГИЕ ФАЙЛЫ.
-# Все переопределения переменных — ТОЛЬКО через terraform CLI опцию -var.
-# Файл terraform.tfvars ЧИТАЕТСЯ, но НИКОГДА НЕ ПЕРЕЗАПИСЫВАЕТСЯ.
-#
-# ЗАПРЕЩЕНО:
-#   - Редактировать этот скрипт
-#   - Редактировать terraform.tfvars
-#   - Редактировать любые .tf файлы
-#   - Запускать terraform напрямую — только через этот скрипт
-#
-# ПРИЧИНА: предыдущая версия скрипта уничтожила terraform.tfvars
-# через write_tfvars() — потерян JWT-токен api_token. Это НЕДОПУСТИМО.
-#
-# ФАЗЫ:
-#   1  BASELINE         — apply с текущим tfvars (packages + nginx + docker)
-#   2  IDEMPOTENT       — повторный plan → "No changes"
-#   3  PARTIAL_DISABLE  — apply с -var install_nginx=false -var install_docker=false
-#   4  PARTIAL_ENABLE   — apply с -var install_nginx=true -var install_docker=true (run_id+1)
-#   5  REORDER_PACKAGES — apply с -var 'base_packages=["htop","jq"]' (run_id+1)
-#   6  MANUAL_PURGE     — удалить пакеты с VM по SSH → apply (run_id+1)
-#   7  DESTROY          — terraform destroy → VM уходит в suspend
-#   8  RESURRECT        — apply после destroy → VM просыпается
-#   9  STRESS_CYCLES    — N подряд destroy/apply циклов
-#  10  FINAL_SANITY     — проверить доступность VM и пакеты
-#
-# ЗАПУСК:
-#   cd ~/terra/sless/examples/VM
-#   bash vm_stress_test.sh 2>&1 | tee /tmp/vm_stress_$(date +%Y%m%d_%H%M).log
-#
-# ПАРАМЕТРЫ (env):
-#   STRESS_CYCLES=2   — количество destroy/apply циклов в фазе 9 (default: 2)
-#   SKIP_DESTROY=1    — пропустить фазы 7-9 (для быстрого прогона)
-#
-# АНАЛИЗ РЕЗУЛЬТАТОВ:
-#   grep -E '\[(PASS|FAIL|SKIP)\]' /tmp/vm_stress.log
-#   Итоговая сводка печатается в конце лога.
-#
-# ТРЕБОВАНИЯ: terraform, ssh, python3 — всё на VM naeel@5.172.178.213
-
-set -uo pipefail
-
-# ── CONFIG ────────────────────────────────────────────────────────────────────
-
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-cd "$SCRIPT_DIR"
-
-VM_KEY="$SCRIPT_DIR/vm_key"
-STRESS_CYCLES="${STRESS_CYCLES:-2}"
-SKIP_DESTROY="${SKIP_DESTROY:-0}"
-
-# Читаем текущий run_id из terraform.tfvars (ТОЛЬКО ЧТЕНИЕ, не запись)
-RUN_ID=$(grep 'install_run_id' terraform.tfvars | grep -oP '\d+' | head -1)
-
-# ── СТАТИСТИКА ────────────────────────────────────────────────────────────────
-
-PASS=0; FAIL=0; SKIP=0
-PHASE_RESULTS=()
-START_TIME=$SECONDS
-
-# ── ЦВЕТА ─────────────────────────────────────────────────────────────────────
-
-GREEN='\033[0;32m'; RED='\033[0;31m'; YELLOW='\033[1;33m'
-CYAN='\033[0;36m'; BOLD='\033[1m'; RESET='\033[0m'
-
-# ── HELPERS ───────────────────────────────────────────────────────────────────
-
-pass()    { echo -e "  ${GREEN}[PASS]${RESET} $1"; ((PASS++)); }
-fail()    { echo -e "  ${RED}[FAIL]${RESET} $1"; ((FAIL++)); }
-skip()    { echo -e "  ${YELLOW}[SKIP]${RESET} $1"; ((SKIP++)); }
-info()    { echo -e "  ${CYAN}[INFO]${RESET} $1"; }
-warn()    { echo -e "  ${YELLOW}[WARN]${RESET} $1"; }
-
-phase_header() {
-    local num="$1" name="$2"
-    echo ""
-    echo -e "${BOLD}${CYAN}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-    echo -e "${BOLD}${CYAN}  ФАЗА $num: $name${RESET}"
-    echo -e "${BOLD}${CYAN}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-    echo -e "  ${CYAN}[TIME]${RESET} $(date '+%H:%M:%S')"
-}
-
-phase_result() {
-    local name="$1" result="$2"
-    PHASE_RESULTS+=("$name:$result")
-    echo -e "  ${CYAN}[PHASE]${RESET} $name → ${result}"
-}
-
-# ── TERRAFORM HELPERS ─────────────────────────────────────────────────────────
-# ⛔ НЕ ТРОГАЕМ terraform.tfvars. Переопределения — ТОЛЬКО через -var.
-# terraform.tfvars подхватывается автоматически (лежит в рабочей директории).
-# Доп. -var аргументы передаются во все tf_* функции и ПЕРЕОПРЕДЕЛЯЮТ tfvars.
-
-# tf_apply: apply с retry при сетевых ошибках.
-# Аргументы: любые доп. -var (опционально).
-# Пример: tf_apply -var install_nginx=false -var install_docker=false
-tf_apply() {
-    local attempt=1 max=3
-    while [[ $attempt -le $max ]]; do
-        info "terraform apply (попытка $attempt/$max)..."
-        if terraform apply -auto-approve -input=false -no-color "$@" 2>&1 | tee /tmp/vm_tf_apply.log; then
-            return 0
-        fi
-        if grep -Eiq 'TLS handshake timeout|unexpected EOF|i/o timeout|context deadline|Client\.Timeout' /tmp/vm_tf_apply.log && [[ $attempt -lt $max ]]; then
-            warn "сетевой сбой, retry через $((attempt * 5))s..."
-            sleep $((attempt * 5))
-            ((attempt++))
-            continue
-        fi
-        return 1
-    done
-    return 1
-}
-
-# tf_destroy: destroy с retry.
-# Аргументы: любые доп. -var (опционально).
-tf_destroy() {
-    local attempt=1 max=3
-    while [[ $attempt -le $max ]]; do
-        info "terraform destroy (попытка $attempt/$max)..."
-        if terraform destroy -auto-approve -input=false -no-color "$@" 2>&1 | tee /tmp/vm_tf_destroy.log; then
-            return 0
-        fi
-        if grep -Eiq 'TLS handshake timeout|unexpected EOF|i/o timeout|context deadline|Client\.Timeout' /tmp/vm_tf_destroy.log && [[ $attempt -lt $max ]]; then
-            warn "сетевой сбой, retry через $((attempt * 5))s..."
-            sleep $((attempt * 5))
-            ((attempt++))
-            continue
-        fi
-        return 1
-    done
-    return 1
-}
-
-# tf_plan_no_changes: проверить plan → "No changes".
-# Аргументы: любые доп. -var (опционально).
-tf_plan_no_changes() {
-    terraform plan -input=false -no-color "$@" 2>&1 | tee /tmp/vm_tf_plan.log
-    grep -q 'No changes' /tmp/vm_tf_plan.log
-}
-
-# tf_state_count: количество ресурсов в state.
-tf_state_count() {
-    terraform state list 2>/dev/null | wc -l
-}
-
-# next_run_id: инкрементировать внутренний счётчик RUN_ID и вернуть новое значение.
-# Используется для -var install_run_id=N чтобы форсировать пересоздание jobs.
-next_run_id() {
-    RUN_ID=$((RUN_ID + 1))
-    echo "$RUN_ID"
-}
-
-# ── VM SSH HELPERS ────────────────────────────────────────────────────────────
-
-# get_vm_ip: получить внешний IP VM из terraform output.
-get_vm_ip() {
-    terraform output -json vm_state 2>/dev/null \
-        | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('externalConnect',''))" 2>/dev/null
-}
-
-# vm_ssh: выполнить команду на VM. Возвращает exit code команды.
-vm_ssh() {
-    local ip="$1"; shift
-    ssh -i "$VM_KEY" -o StrictHostKeyChecking=no -o ConnectTimeout=15 \
-        -o ServerAliveInterval=5 -o ServerAliveCountMax=3 \
-        "ubuntu@$ip" "$@"
-}
-
-# vm_alive: проверить доступность VM по SSH.
-vm_alive() {
-    local ip="$1"
-    vm_ssh "$ip" 'echo alive' &>/dev/null
-}
-
-# vm_wait_alive: ждать пока VM ответит по SSH (до timeout_sec).
-vm_wait_alive() {
-    local ip="$1" timeout_sec="${2:-120}"
-    local deadline=$((SECONDS + timeout_sec))
-    while [[ $SECONDS -lt $deadline ]]; do
-        if vm_alive "$ip"; then return 0; fi
-        sleep 10
-    done
-    return 1
-}
-
-# vm_check_package: проверить что пакет установлен.
-vm_check_package() {
-    local ip="$1" pkg="$2"
-    vm_ssh "$ip" "dpkg -l $pkg 2>/dev/null | grep -q '^ii'" 2>/dev/null
-}
-
-# vm_check_binary: проверить что бинарник доступен.
-vm_check_binary() {
-    local ip="$1" bin="$2"
-    vm_ssh "$ip" "command -v $bin" &>/dev/null
-}
-
-# vm_wait_binary: ждать пока бинарник появится на VM (sless_job работает асинхронно).
-# Нужен потому что sless_job запускает kubernetes Job, который сначала собирает образ,
-# затем стартует pod, и только потом SSH-устанавливает пакеты на VM — это занимает 1-3 мин.
-vm_wait_binary() {
-    local ip="$1" bin="$2" timeout_sec="${3:-180}"
-    local deadline=$((SECONDS + timeout_sec))
-    info "жду появления '$bin' на VM (до ${timeout_sec}s)..."
-    while [[ $SECONDS -lt $deadline ]]; do
-        if vm_check_binary "$ip" "$bin"; then return 0; fi
-        sleep 15
-    done
-    return 1
-}
-
-# vm_purge_all: удалить все установленные пакеты с VM.
-vm_purge_all() {
-    local ip="$1"
-    info "удаляю пакеты с VM $ip..."
-    vm_ssh "$ip" 'sudo systemctl stop nginx docker 2>/dev/null; sudo apt-get purge -y jq python3-pip htop unzip nginx docker-ce docker-ce-cli containerd.io docker-compose-plugin 2>/dev/null; sudo apt-get autoremove -y 2>/dev/null; sudo rm -rf /var/lib/docker /var/lib/containerd; echo purge_done' 2>/dev/null
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 1: BASELINE — apply с текущим tfvars (всё включено)
-# Используем -var install_run_id=N чтобы гарантировать свежий запуск.
-# terraform.tfvars НЕ ТРОГАЕМ — берём как есть.
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_1_baseline() {
-    phase_header 1 "BASELINE — apply с полным набором"
-
-    local rid
-    rid=$(next_run_id)
-
-    # Все флаги = true (как в tfvars), но run_id инкрементирован
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$rid"; then
-        pass "1.1 terraform apply завершился успешно"
-    else
-        fail "1.1 terraform apply упал"
-        phase_result "BASELINE" "FAIL"
-        return 1
-    fi
-
-    # Проверить количество ресурсов
-    local count
-    count=$(tf_state_count)
-    if [[ $count -ge 5 ]]; then
-        pass "1.2 state содержит $count ресурсов (ожидали ≥5)"
-    else
-        fail "1.2 state содержит $count ресурсов (ожидали ≥5)"
-    fi
-
-    # Проверить outputs
-    local out
-    out=$(terraform output -json 2>/dev/null)
-
-    if echo "$out" | python3 -c "import sys,json; d=json.load(sys.stdin); assert 'ok' in d['install_packages_result']['value'] or 'already' in d['install_packages_result']['value']" 2>/dev/null; then
-        pass "1.3 install_packages_result содержит ok/already_installed"
-    else
-        fail "1.3 install_packages_result не содержит ok"
-    fi
-
-    if echo "$out" | python3 -c "import sys,json; d=json.load(sys.stdin); v=d['install_nginx_result']['value']; assert 'ok' in v or 'already' in v" 2>/dev/null; then
-        pass "1.4 install_nginx_result содержит ok/already"
-    else
-        fail "1.4 install_nginx_result не содержит ok"
-    fi
-
-    if echo "$out" | python3 -c "import sys,json; d=json.load(sys.stdin); v=d['install_docker_result']['value']; assert 'ok' in v or 'already' in v" 2>/dev/null; then
-        pass "1.5 install_docker_result содержит ok/already"
-    else
-        fail "1.5 install_docker_result не содержит ok"
-    fi
-
-    # Проверить VM по SSH
-    local ip
-    ip=$(get_vm_ip)
-    if [[ -n "$ip" ]] && vm_alive "$ip"; then
-        pass "1.6 VM $ip доступна по SSH"
-    else
-        fail "1.6 VM не доступна по SSH (ip=$ip)"
-    fi
-
-    phase_result "BASELINE" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 2: IDEMPOTENT — повторный apply с теми же аргументами → 0 changed
-# Используем apply (не plan) — это надёжнее: некоторые sless-провайдеры показывают
-# ложный drift в plan, но apply при этом возвращает 0 changed. Apply — canonical way.
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_2_idempotent() {
-    phase_header 2 "IDEMPOTENT — повторный apply без изменений"
-
-    # Тот же run_id что применялся в фазе 1 → apply должен вернуть 0 changed
-    # sless_job — эфемерный ресурс, каждый apply пересоздаёт job-ресурсы (add+destroy).
-    # Идемпотентность = "0 changed" (ноль in-place изменений), а не "0 add/destroy".
-    # VM и vApp не должны изменяться никогда.
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$RUN_ID"; then
-        if grep -q ', 0 changed,' /tmp/vm_tf_apply.log; then
-            pass "2.1 повторный apply → 0 changed (sless_job пересоздан — ожидаемо)"
-            grep -E 'Resources:' /tmp/vm_tf_apply.log | tail -1 | while read -r line; do
-                info "  $line"
-            done
-        else
-            fail "2.1 повторный apply изменил persistent ресурсы (ожидали 0 changed)"
-            grep -E 'added|changed|destroyed' /tmp/vm_tf_apply.log | tail -3 | while read -r line; do
-                info "  $line"
-            done
-        fi
-    else
-        fail "2.1 повторный apply упал"
-    fi
-
-    phase_result "IDEMPOTENT" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 3: PARTIAL_DISABLE — выключить nginx + docker
-# Используем -var install_nginx=false -var install_docker=false
-# terraform.tfvars по-прежнему НЕ ТРОГАЕМ.
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_3_partial_disable() {
-    phase_header 3 "PARTIAL_DISABLE — выключить nginx + docker"
-
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=false" \
-        -var "install_docker=false" \
-        -var "install_run_id=$RUN_ID"; then
-        pass "3.1 apply с partial disable завершился"
-    else
-        fail "3.1 apply с partial disable упал"
-        phase_result "PARTIAL_DISABLE" "FAIL"
-        return 1
-    fi
-
-    # Проверить что nginx и docker job пропали из state
-    local state_list
-    state_list=$(terraform state list 2>/dev/null)
-
-    if echo "$state_list" | grep -q 'install_nginx'; then
-        fail "3.2 install_nginx всё ещё в state"
-    else
-        pass "3.2 install_nginx убран из state"
-    fi
-
-    if echo "$state_list" | grep -q 'install_docker'; then
-        fail "3.3 install_docker всё ещё в state"
-    else
-        pass "3.3 install_docker убран из state"
-    fi
-
-    if echo "$state_list" | grep -q 'install_packages'; then
-        pass "3.4 install_packages остался в state"
-    else
-        fail "3.4 install_packages пропал из state"
-    fi
-
-    # Проверить outputs
-    local nginx_out docker_out
-    nginx_out=$(terraform output -raw install_nginx_result 2>/dev/null)
-    docker_out=$(terraform output -raw install_docker_result 2>/dev/null)
-
-    if [[ "$nginx_out" == "skipped" ]]; then
-        pass "3.5 install_nginx_result = skipped"
-    else
-        fail "3.5 install_nginx_result = '$nginx_out' (ожидали skipped)"
-    fi
-
-    if [[ "$docker_out" == "skipped" ]]; then
-        pass "3.6 install_docker_result = skipped"
-    else
-        fail "3.6 install_docker_result = '$docker_out' (ожидали skipped)"
-    fi
-
-    phase_result "PARTIAL_DISABLE" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 4: PARTIAL_ENABLE — включить обратно всё
-# Инкрементируем run_id чтобы jobs пересоздались.
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_4_partial_enable() {
-    phase_header 4 "PARTIAL_ENABLE — включить обратно всё"
-
-    local rid
-    rid=$(next_run_id)
-
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$rid"; then
-        pass "4.1 apply с полным набором завершился"
-    else
-        fail "4.1 apply с полным набором упал"
-        phase_result "PARTIAL_ENABLE" "FAIL"
-        return 1
-    fi
-
-    local count
-    count=$(tf_state_count)
-    if [[ $count -ge 5 ]]; then
-        pass "4.2 state содержит $count ресурсов (ожидали ≥5)"
-    else
-        fail "4.2 state содержит $count ресурсов (ожидали ≥5)"
-    fi
-
-    phase_result "PARTIAL_ENABLE" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 5: REORDER_PACKAGES — изменить порядок и состав base_packages
-# Через -var 'base_packages=["htop","jq"]' — terraform.tfvars не трогаем.
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_5_reorder() {
-    phase_header 5 "REORDER_PACKAGES — изменить порядок и состав пакетов"
-
-    local rid
-    rid=$(next_run_id)
-
-    # Сокращённый набор пакетов через -var
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$rid" \
-        -var 'base_packages=["htop","jq"]'; then
-        pass "5.1 apply с изменённым набором пакетов завершился"
-    else
-        fail "5.1 apply с изменённым набором пакетов упал"
-        phase_result "REORDER_PACKAGES" "FAIL"
-        return 1
-    fi
-
-    # Проверить output
-    local pkg_out
-    pkg_out=$(terraform output -raw install_packages_result 2>/dev/null)
-    if echo "$pkg_out" | grep -qE '"status"|ok|already'; then
-        pass "5.2 install_packages вернул ожидаемый результат"
-    else
-        fail "5.2 install_packages output неожиданный: $pkg_out"
-    fi
-
-    # Вернуть полный набор пакетов
-    rid=$(next_run_id)
-    tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$rid" \
-        || warn "5.3 восстановление полного набора не удалось"
-
-    phase_result "REORDER_PACKAGES" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 6: MANUAL_PURGE — удалить пакеты с VM вручную, заново установить
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_6_manual_purge() {
-    phase_header 6 "MANUAL_PURGE — удалить пакеты с VM, заново установить"
-
-    local ip
-    ip=$(get_vm_ip)
-    if [[ -z "$ip" ]]; then
-        fail "6.0 не удалось получить IP VM"
-        phase_result "MANUAL_PURGE" "FAIL"
-        return 1
-    fi
-
-    # Удалить всё с VM
-    vm_purge_all "$ip"
-
-    # Проверить что пакеты действительно удалены
-    if vm_check_binary "$ip" "docker"; then
-        fail "6.1 docker всё ещё на VM после purge"
-    else
-        pass "6.1 docker удалён с VM"
-    fi
-
-    if vm_check_binary "$ip" "nginx"; then
-        fail "6.2 nginx всё ещё на VM после purge"
-    else
-        pass "6.2 nginx удалён с VM"
-    fi
-
-    if vm_check_binary "$ip" "jq"; then
-        fail "6.3 jq всё ещё на VM после purge"
-    else
-        pass "6.3 jq удалён с VM"
-    fi
-
-    # Пересоздать jobs (bump run_id)
-    local rid
-    rid=$(next_run_id)
-
-    info "запускаю переустановку через sless_job..."
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$rid"; then
-        pass "6.4 apply после purge завершился"
-    else
-        fail "6.4 apply после purge упал"
-        phase_result "MANUAL_PURGE" "FAIL"
-        return 1
-    fi
-
-    # Ждать пока sless_job отработает: docker самый долгий (k8s Job + образ + apt-install ~200MB).
-    # docker-ce требует до 5 минут на первой установке — ставим 360s.
-    if vm_wait_binary "$ip" "docker" 360; then
-        pass "6.5 docker установлен заново"
-    else
-        fail "6.5 docker НЕ установлен после re-apply (таймаут 360s)"
-    fi
-
-    if vm_wait_binary "$ip" "nginx" 240; then
-        pass "6.6 nginx установлен заново"
-    else
-        fail "6.6 nginx НЕ установлен после re-apply (таймаут 240s)"
-    fi
-
-    if vm_check_binary "$ip" "jq"; then
-        pass "6.7 jq установлен заново"
-    else
-        fail "6.7 jq НЕ установлен после re-apply"
-    fi
-
-    phase_result "MANUAL_PURGE" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 7: DESTROY — terraform destroy, VM уходит в suspend
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_7_destroy() {
-    phase_header 7 "DESTROY — terraform destroy → VM в suspend"
-
-    local ip
-    ip=$(get_vm_ip)
-
-    if tf_destroy; then
-        pass "7.1 terraform destroy завершился"
-    else
-        fail "7.1 terraform destroy упал"
-        phase_result "DESTROY" "FAIL"
-        return 1
-    fi
-
-    # State должен быть пуст
-    local count
-    count=$(tf_state_count)
-    if [[ $count -eq 0 ]]; then
-        pass "7.2 state пуст ($count ресурсов)"
-    else
-        fail "7.2 state не пуст ($count ресурсов)"
-    fi
-
-    # VM не должна отвечать по SSH
-    if [[ -n "$ip" ]]; then
-        info "проверяю что VM $ip недоступна..."
-        if vm_alive "$ip"; then
-            fail "7.3 VM $ip всё ещё отвечает по SSH после destroy"
-        else
-            pass "7.3 VM $ip не отвечает по SSH (suspend подтверждён)"
-        fi
-    else
-        skip "7.3 IP VM неизвестен, пропускаю SSH-проверку"
-    fi
-
-    phase_result "DESTROY" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 8: RESURRECT — apply после destroy, VM просыпается
-# Используем текущий run_id — terraform.tfvars НЕ ТРОГАЕМ.
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_8_resurrect() {
-    phase_header 8 "RESURRECT — apply после destroy"
-
-    local rid
-    rid=$(next_run_id)
-
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$rid"; then
-        pass "8.1 apply после destroy завершился"
-    else
-        fail "8.1 apply после destroy упал"
-        phase_result "RESURRECT" "FAIL"
-        return 1
-    fi
-
-    local count
-    count=$(tf_state_count)
-    if [[ $count -ge 5 ]]; then
-        pass "8.2 state содержит $count ресурсов"
-    else
-        fail "8.2 state содержит $count ресурсов (ожидали ≥5)"
-    fi
-
-    # Проверить VM
-    local ip
-    ip=$(get_vm_ip)
-    if [[ -n "$ip" ]] && vm_alive "$ip"; then
-        pass "8.3 VM $ip доступна по SSH после resurrect"
-    else
-        # VM может ещё просыпаться — ждём
-        info "VM не отвечает, жду до 120s..."
-        if vm_wait_alive "$ip" 120; then
-            pass "8.3 VM $ip доступна по SSH после ожидания"
-        else
-            fail "8.3 VM $ip не доступна по SSH через 120s"
-        fi
-    fi
-
-    # Проверить пакеты
-    if [[ -n "$ip" ]] && vm_alive "$ip"; then
-        if vm_check_binary "$ip" "jq"; then
-            pass "8.4 jq установлен после resurrect"
-        else
-            fail "8.4 jq НЕ установлен после resurrect"
-        fi
-
-        if vm_check_binary "$ip" "nginx"; then
-            pass "8.5 nginx установлен после resurrect"
-        else
-            fail "8.5 nginx НЕ установлен после resurrect"
-        fi
-
-        if vm_check_binary "$ip" "docker"; then
-            pass "8.6 docker установлен после resurrect"
-        else
-            fail "8.6 docker НЕ установлен после resurrect"
-        fi
-    fi
-
-    phase_result "RESURRECT" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 9: STRESS_CYCLES — N destroy/apply циклов подряд
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_9_stress() {
-    phase_header 9 "STRESS_CYCLES — $STRESS_CYCLES циклов destroy/apply"
-
-    local i rid
-    for i in $(seq 1 "$STRESS_CYCLES"); do
-        info "── цикл $i/$STRESS_CYCLES ──"
-
-        info "[$i] destroy..."
-        if tf_destroy; then
-            pass "9.${i}a destroy цикл $i"
-        else
-            fail "9.${i}a destroy цикл $i упал"
-            # Попробовать восстановиться
-            rid=$(next_run_id)
-            tf_apply \
-                -var "install_packages=true" \
-                -var "install_nginx=true" \
-                -var "install_docker=true" \
-                -var "install_run_id=$rid" || true
-            continue
-        fi
-
-        rid=$(next_run_id)
-        info "[$i] apply (run_id=$rid)..."
-        if tf_apply \
-            -var "install_packages=true" \
-            -var "install_nginx=true" \
-            -var "install_docker=true" \
-            -var "install_run_id=$rid"; then
-            pass "9.${i}b apply цикл $i"
-        else
-            fail "9.${i}b apply цикл $i упал"
-            continue
-        fi
-    done
-
-    phase_result "STRESS_CYCLES" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# ФАЗА 10: FINAL_SANITY — финальная проверка состояния
-# ══════════════════════════════════════════════════════════════════════════════
-
-phase_10_final() {
-    phase_header 10 "FINAL_SANITY — финальная проверка"
-
-    # Убедиться что state на месте
-    local count
-    count=$(tf_state_count)
-    if [[ $count -ge 5 ]]; then
-        pass "10.1 state содержит $count ресурсов"
-    else
-        fail "10.1 state содержит $count ресурсов (ожидали ≥5)"
-        # Попробовать восстановить (через -var, БЕЗ изменения файлов)
-        local rid
-        rid=$(next_run_id)
-        info "пытаюсь восстановить baseline..."
-        tf_apply \
-            -var "install_packages=true" \
-            -var "install_nginx=true" \
-            -var "install_docker=true" \
-            -var "install_run_id=$rid" || warn "восстановление не удалось"
-    fi
-
-    # Idempotency финально: повторный apply → 0 changed.
-    # sless_job пересоздаются (add+destroy) — это нормально для job-ресурса.
-    # Проверяем только "0 changed" — VM и vApp не должны изменяться.
-    if tf_apply \
-        -var "install_packages=true" \
-        -var "install_nginx=true" \
-        -var "install_docker=true" \
-        -var "install_run_id=$RUN_ID"; then
-        if grep -q ', 0 changed,' /tmp/vm_tf_apply.log; then
-            pass "10.2 финальный apply → 0 changed (sless_job пересоздан — ожидаемо)"
-            grep -E 'Resources:' /tmp/vm_tf_apply.log | tail -1 | while read -r line; do
-                info "  $line"
-            done
-        else
-            fail "10.2 финальный apply изменил persistent ресурсы (ожидали 0 changed)"
-            grep -E 'added|changed|destroyed' /tmp/vm_tf_apply.log | tail -3 | while read -r line; do
-                info "  $line"
-            done
-        fi
-    else
-        fail "10.2 финальный apply упал"
-    fi
-
-    # VM доступна
-    local ip
-    ip=$(get_vm_ip)
-    if [[ -n "$ip" ]] && vm_alive "$ip"; then
-        pass "10.3 VM $ip доступна по SSH"
-
-        # Полная проверка пакетов
-        for pkg in jq htop unzip; do
-            if vm_check_package "$ip" "$pkg"; then
-                pass "10.4 пакет $pkg установлен"
-            else
-                fail "10.4 пакет $pkg НЕ установлен"
-            fi
-        done
-
-        if vm_check_binary "$ip" "nginx"; then
-            pass "10.5 nginx работает"
-        else
-            fail "10.5 nginx НЕ найден"
-        fi
-
-        if vm_check_binary "$ip" "docker"; then
-            pass "10.6 docker работает"
-        else
-            fail "10.6 docker НЕ найден"
-        fi
-
-        # nginx service активен (не просто бинарник, а именно демон)
-        if vm_ssh "$ip" "systemctl is-active nginx 2>/dev/null" 2>/dev/null | grep -q '^active$'; then
-            pass "10.7 nginx service активен (systemctl)"
-        else
-            fail "10.7 nginx service не активен"
-        fi
-
-        # docker daemon активен
-        if vm_ssh "$ip" "systemctl is-active docker 2>/dev/null" 2>/dev/null | grep -q '^active$'; then
-            pass "10.8 docker daemon активен (systemctl)"
-        else
-            fail "10.8 docker daemon не активен"
-        fi
-
-        # HTTP probe: nginx отвечает на localhost:80
-        local http_code
-        http_code=$(vm_ssh "$ip" "curl -sS -o /dev/null -w '%{http_code}' http://localhost 2>/dev/null" 2>/dev/null)
-        if [[ "$http_code" == "200" ]]; then
-            pass "10.9 nginx отвечает HTTP 200"
-        else
-            fail "10.9 nginx не отвечает HTTP 200 (code='$http_code')"
-        fi
-
-        # python3 доступен
-        local py_ver
-        py_ver=$(vm_ssh "$ip" "python3 --version 2>&1" 2>/dev/null)
-        if echo "$py_ver" | grep -q 'Python 3'; then
-            pass "10.10 python3 доступен ($py_ver)"
-        else
-            fail "10.10 python3 недоступен"
-        fi
-
-        # docker smoke: запустить контейнер и проверить вывод
-        if vm_ssh "$ip" "docker run --rm hello-world 2>&1 | grep -q 'Hello from Docker'" 2>/dev/null; then
-            pass "10.11 docker run hello-world → успешно"
-        else
-            fail "10.11 docker run hello-world → не прошёл"
-        fi
-
-        # disk space: убедиться что на VM есть место (>500MB free)
-        local free_mb
-        free_mb=$(vm_ssh "$ip" "df -m / 2>/dev/null | awk 'NR==2{print \$4}'" 2>/dev/null)
-        if [[ -n "$free_mb" && "$free_mb" -gt 500 ]]; then
-            pass "10.12 свободное место на / = ${free_mb}MB (>500MB)"
-        else
-            fail "10.12 мало места на / = ${free_mb}MB (ожидали >500MB)"
-        fi
-    else
-        fail "10.3 VM не доступна по SSH"
-    fi
-
-    phase_result "FINAL_SANITY" "PASS"
-}
-
-# ══════════════════════════════════════════════════════════════════════════════
-# MAIN
-# ══════════════════════════════════════════════════════════════════════════════
-
-echo -e "${BOLD}${CYAN}"
-echo "╔═══════════════════════════════════════════════════════════════╗"
-echo "║     VM STRESS TEST v2 (READ-ONLY) — examples/VM             ║"
-echo "║     $(date '+%Y-%m-%d %H:%M:%S')                                     ║"
-echo "║     Начальный run_id: $RUN_ID                                        ║"
-echo "║     Циклов stress: $STRESS_CYCLES                                       ║"
-echo "║     terraform.tfvars НЕ МОДИФИЦИРУЕТСЯ                      ║"
-echo "╚═══════════════════════════════════════════════════════════════╝"
-echo -e "${RESET}"
-
-# Проверить что мы в правильной директории
-if [[ ! -f "terraform.tfvars" ]]; then
-    echo -e "${RED}ОШИБКА: terraform.tfvars не найден. Запускайте из examples/VM/${RESET}"
-    exit 1
-fi
-
-if [[ ! -f "$VM_KEY" ]]; then
-    echo -e "${RED}ОШИБКА: $VM_KEY не найден${RESET}"
-    exit 1
-fi
-
-# ⛔ ПРОВЕРКА ЦЕЛОСТНОСТИ: terraform.tfvars НЕ ДОЛЖЕН БЫТЬ МОДИФИЦИРОВАН
-# Сохраняем md5 до запуска и проверяем после каждой фазы
-TFVARS_MD5=$(md5sum terraform.tfvars | awk '{print $1}')
-info "md5 terraform.tfvars = $TFVARS_MD5 (будет проверяться после каждой фазы)"
-
-check_tfvars_integrity() {
-    local current_md5
-    current_md5=$(md5sum terraform.tfvars | awk '{print $1}')
-    if [[ "$current_md5" != "$TFVARS_MD5" ]]; then
-        echo -e "${RED}⛔⛔⛔ КРИТИЧЕСКАЯ ОШИБКА: terraform.tfvars был изменён! ⛔⛔⛔${RESET}"
-        echo -e "${RED}Ожидали md5: $TFVARS_MD5${RESET}"
-        echo -e "${RED}Текущий md5: $current_md5${RESET}"
-        echo -e "${RED}АВАРИЙНАЯ ОСТАНОВКА ТЕСТА${RESET}"
-        exit 99
-    fi
-}
-
-# Запуск фаз с проверкой целостности после каждой
-phase_1_baseline;  check_tfvars_integrity
-phase_2_idempotent;  check_tfvars_integrity
-phase_3_partial_disable;  check_tfvars_integrity
-phase_4_partial_enable;  check_tfvars_integrity
-phase_5_reorder;  check_tfvars_integrity
-phase_6_manual_purge;  check_tfvars_integrity
-
-if [[ "$SKIP_DESTROY" == "1" ]]; then
-    skip "фазы 7-9 пропущены (SKIP_DESTROY=1)"
-    PHASE_RESULTS+=("DESTROY:SKIP" "RESURRECT:SKIP" "STRESS_CYCLES:SKIP")
-else
-    phase_7_destroy;  check_tfvars_integrity
-    phase_8_resurrect;  check_tfvars_integrity
-    phase_9_stress;  check_tfvars_integrity
-fi
-
-phase_10_final;  check_tfvars_integrity
-
-# ── ИТОГОВАЯ СВОДКА ──────────────────────────────────────────────────────────
-
-ELAPSED=$((SECONDS - START_TIME))
-ELAPSED_MIN=$((ELAPSED / 60))
-ELAPSED_SEC=$((ELAPSED % 60))
-
-echo ""
-echo -e "${BOLD}${CYAN}╔═══════════════════════════════════════════════════════════════╗${RESET}"
-echo -e "${BOLD}${CYAN}║                    ИТОГОВАЯ СВОДКА                           ║${RESET}"
-echo -e "${BOLD}${CYAN}╠═══════════════════════════════════════════════════════════════╣${RESET}"
-echo -e "${BOLD}  Время: ${ELAPSED_MIN}m ${ELAPSED_SEC}s${RESET}"
-echo -e "${BOLD}  ${GREEN}PASS: $PASS${RESET}  ${RED}FAIL: $FAIL${RESET}  ${YELLOW}SKIP: $SKIP${RESET}"
-echo -e "${BOLD}  Финальный run_id: $RUN_ID${RESET}"
-echo ""
-echo -e "${BOLD}  Фазы:${RESET}"
-for pr in "${PHASE_RESULTS[@]}"; do
-    name="${pr%%:*}"
-    result="${pr##*:}"
-    case "$result" in
-        PASS) echo -e "    ${GREEN}✓${RESET} $name" ;;
-        FAIL) echo -e "    ${RED}✗${RESET} $name" ;;
-        SKIP) echo -e "    ${YELLOW}○${RESET} $name" ;;
-    esac
-done
-echo -e "${BOLD}${CYAN}╚═══════════════════════════════════════════════════════════════╝${RESET}"
-
-# Финальная проверка целостности tfvars
-check_tfvars_integrity
-info "terraform.tfvars НЕ БЫЛ ИЗМЕНЁН (md5 совпадает)"
-
-# Exit code: 0 если все PASS, 1 если есть FAIL
-if [[ $FAIL -gt 0 ]]; then
-    echo -e "\n${RED}РЕЗУЛЬТАТ: FAIL ($FAIL ошибок)${RESET}"
-    exit 1
-else
-    echo -e "\n${GREEN}РЕЗУЛЬТАТ: ALL PASS${RESET}"
-    exit 0
-fi

go.mod

@@ -19,7 +19,6 @@ require (
 	github.com/cespare/xxhash/v2 v2.1.2 // indirect
 	github.com/davecgh/go-spew v1.1.1 // indirect
 	github.com/dustin/go-humanize v1.0.1 // indirect
-	github.com/eclipse/paho.mqtt.golang v1.5.1 // indirect
 	github.com/emicklei/go-restful/v3 v3.9.0 // indirect
 	github.com/evanphx/json-patch/v5 v5.6.0 // indirect
 	github.com/fsnotify/fsnotify v1.6.0 // indirect
@@ -36,7 +35,6 @@ require (
 	github.com/google/go-cmp v0.5.9 // indirect
 	github.com/google/gofuzz v1.1.0 // indirect
 	github.com/google/uuid v1.6.0 // indirect
-	github.com/gorilla/websocket v1.5.3 // indirect
 	github.com/imdario/mergo v0.3.6 // indirect
 	github.com/josharian/intern v1.0.0 // indirect
 	github.com/json-iterator/go v1.1.12 // indirect
@@ -67,7 +65,6 @@ require (
 	golang.org/x/crypto v0.46.0 // indirect
 	golang.org/x/net v0.48.0 // indirect
 	golang.org/x/oauth2 v0.0.0-20220223155221-ee480838109b // indirect
-	golang.org/x/sync v0.19.0 // indirect
 	golang.org/x/sys v0.39.0 // indirect
 	golang.org/x/term v0.38.0 // indirect
 	golang.org/x/text v0.32.0 // indirect

go.sum

@@ -60,8 +60,6 @@ github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSs
 github.com/docopt/docopt-go v0.0.0-20180111231733-ee0de3bc6815/go.mod h1:WwZ+bS3ebgob9U8Nd0kOddGdZWjyMGR8Wziv+TBNwSE=
 github.com/dustin/go-humanize v1.0.1 h1:GzkhY7T5VNhEkwH0PVJgjz+fX1rhBrR7pRT3mDkpeCY=
 github.com/dustin/go-humanize v1.0.1/go.mod h1:Mu1zIs6XwVuF/gI1OepvI0qD18qycQx+mFykh5fBlto=
-github.com/eclipse/paho.mqtt.golang v1.5.1 h1:/VSOv3oDLlpqR2Epjn1Q7b2bSTplJIeV2ISgCl2W7nE=
-github.com/eclipse/paho.mqtt.golang v1.5.1/go.mod h1:1/yJCneuyOoCOzKSsOTUc0AJfpsItBGWvYpBLimhArU=
 github.com/emicklei/go-restful/v3 v3.9.0 h1:XwGDlfxEnQZzuopoqxwSEllNcCOM9DhhFyhFIIGKwxE=
 github.com/emicklei/go-restful/v3 v3.9.0/go.mod h1:6n3XBCmQQb25CM2LCACGz8ukIrRry+4bhvbpWn3mrbc=
 github.com/envoyproxy/go-control-plane v0.9.0/go.mod h1:YTl/9mNaCwkRvm6d1a2C3ymFceY/DCBVvsKhRF0iEA4=
@@ -170,8 +168,6 @@ github.com/googleapis/gax-go/v2 v2.0.4/go.mod h1:0Wqv26UfaUD9n4G6kQubkQ+KchISgw+
 github.com/googleapis/gax-go/v2 v2.0.5/go.mod h1:DWXyrwAJ9X0FpwwEdw+IPEYBICEFu5mhpdKc/us6bOk=
 github.com/gorilla/mux v1.8.1 h1:TuBL49tXwgrFYWhqrNgrUNEY92u81SPhu7sTdzQEiWY=
 github.com/gorilla/mux v1.8.1/go.mod h1:AKf9I4AEqPTmMytcMc0KkNouC66V3BtZ4qD5fmWSiMQ=
-github.com/gorilla/websocket v1.5.3 h1:saDtZ6Pbx/0u+bgYQ3q96pZgCzfhKXGPqt7kZ72aNNg=
-github.com/gorilla/websocket v1.5.3/go.mod h1:YR8l580nyteQvAITg2hZ9XVh4b55+EU/adAjf1fMHhE=
 github.com/hashicorp/golang-lru v0.5.0/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
 github.com/hashicorp/golang-lru v0.5.1/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
 github.com/ianlancetaylor/demangle v0.0.0-20181102032728-5e5cf60278f6/go.mod h1:aSSvb/t6k1mPoxDqO4vJh6VOCGPwU4O0C2/Eqndh1Sc=
@@ -409,8 +405,6 @@ golang.org/x/sync v0.0.0-20200317015054-43a5402ce75a/go.mod h1:RxMgew5VJxzue5/jJ
 golang.org/x/sync v0.0.0-20200625203802-6e8e738ad208/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20201207232520-09787c993a3a/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
-golang.org/x/sync v0.19.0 h1:vV+1eWNmZ5geRlYjzm2adRgW2/mcpevXNg50YZtPCE4=
-golang.org/x/sync v0.19.0/go.mod h1:9KTHXmSnoGruLpwFjVSX0lNNA75CykiMECbovNTZqGI=
 golang.org/x/sys v0.0.0-20180830151530-49385e6e1522/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
 golang.org/x/sys v0.0.0-20180905080454-ebe1bf3edb33/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
 golang.org/x/sys v0.0.0-20181116152217-5ac8a444bdc5/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=

internal/api/handler/iot_device_handler.go

@@ -1,353 +0,0 @@
-// Создано: 2026-04-04
-// iot_device_handler.go — HTTP handlers для IoT-устройств (CRUD) и MQTT auth.
-//
-// Endpoints:
-//   POST   /internal/mqtt/auth               → MQTTAuth (без JWT, для EMQX)
-//   POST   /v1/namespaces/{ns}/iot/devices   → CreateIoTDevice
-//   GET    /v1/namespaces/{ns}/iot/devices   → ListIoTDevices
-//   GET    /v1/namespaces/{ns}/iot/devices/{name} → GetIoTDevice (включает credentials)
-//   DELETE /v1/namespaces/{ns}/iot/devices/{name} → DeleteIoTDevice
-//   PATCH  /v1/namespaces/{ns}/iot/devices/{name} → UpdateIoTDevice
-//
-// MQTTAuth вызывается EMQX при каждом MQTT CONNECT:
-//   - всегда возвращает HTTP 200 (non-200 = EMQX игнорирует backend)
-//   - {"result": "allow"|"deny"} в теле
-//
-// GetIoTDevice — единственный endpoint возвращающий mqtt-password.
-// ListIoTDevices — без паролей (security by design).
-
-package handler
-
-import (
-	"crypto/subtle"
-	"encoding/json"
-	"net/http"
-	"strings"
-	"time"
-
-	corev1 "k8s.io/api/core/v1"
-	"k8s.io/apimachinery/pkg/api/errors"
-	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
-	"sigs.k8s.io/controller-runtime/pkg/client"
-
-	iotv1alpha1 "gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/api/v1alpha1"
-)
-
-// ——————————————————————————————————————————
-// Типы запросов / ответов
-// ——————————————————————————————————————————
-
-// iotDeviceCreateRequest — тело POST при создании IoTDevice.
-type iotDeviceCreateRequest struct {
-	// Name — имя k8s объекта IoTDevice (должно быть уникальным в namespace)
-	Name string `json:"name"`
-	// DeviceID — идентификатор устройства, используется в MQTT username и имени Secret
-	DeviceID string `json:"device_id"`
-	// Enabled — активно ли устройство с момента создания
-	Enabled *bool `json:"enabled"`
-	// Metadata — произвольные метаданные (модель, локация и т.д.)
-	Metadata map[string]string `json:"metadata,omitempty"`
-}
-
-// iotDeviceUpdateRequest — тело PATCH при обновлении IoTDevice.
-type iotDeviceUpdateRequest struct {
-	// Enabled — включить/отключить устройство
-	Enabled *bool `json:"enabled"`
-}
-
-// iotDeviceResponse — ответ при чтении одного IoTDevice.
-// MQTTPassword заполняется только из GetIoTDevice (чтение из Secret).
-type iotDeviceResponse struct {
-	Name         string                        `json:"name"`
-	Namespace    string                        `json:"namespace"`
-	DeviceID     string                        `json:"device_id"`
-	Enabled      bool                          `json:"enabled"`
-	Phase        iotv1alpha1.IoTDevicePhase    `json:"phase"`
-	MQTTUsername string                        `json:"mqtt_username,omitempty"`
-	MQTTPassword string                        `json:"mqtt_password,omitempty"` // только в GET /devices/{name}
-	SecretName   string                        `json:"secret_name,omitempty"`
-	TopicPrefix  string                        `json:"topic_prefix,omitempty"`
-	LastConnected string                       `json:"last_connected,omitempty"`
-	Message      string                        `json:"message,omitempty"`
-	Metadata     map[string]string             `json:"metadata,omitempty"`
-	CreatedAt    string                        `json:"created_at,omitempty"`
-}
-
-// mqttAuthRequest — тело запроса от EMQX при MQTT CONNECT.
-// EMQX 5.x посылает JSON: username, password, clientid, peerhost.
-type mqttAuthRequest struct {
-	Username string `json:"username"`
-	Password string `json:"password"`
-	ClientID string `json:"clientid"`
-	PeerHost string `json:"peerhost"`
-}
-
-// mqttAuthResponse — ответ для EMQX. Всегда HTTP 200.
-// result = "allow" | "deny"
-type mqttAuthResponse struct {
-	Result string `json:"result"`
-}
-
-// ——————————————————————————————————————————
-// Вспомогательные функции
-// ——————————————————————————————————————————
-
-// deviceToResponse конвертирует IoTDevice CRD в ответ API.
-// password передаётся отдельно — берётся из Secret только в GetIoTDevice.
-func deviceToResponse(d *iotv1alpha1.IoTDevice, password string) iotDeviceResponse {
-	resp := iotDeviceResponse{
-		Name:         d.Name,
-		Namespace:    d.Namespace,
-		DeviceID:     d.Spec.DeviceID,
-		Enabled:      d.Spec.Enabled,
-		Phase:        d.Status.Phase,
-		MQTTUsername: d.Status.MQTTUsername,
-		MQTTPassword: password,
-		SecretName:   d.Status.SecretName,
-		TopicPrefix:  d.Status.TopicPrefix,
-		Message:      d.Status.Message,
-		Metadata:     d.Spec.Metadata,
-	}
-	if d.Status.LastConnected != nil && !d.Status.LastConnected.IsZero() {
-		resp.LastConnected = d.Status.LastConnected.UTC().Format(time.RFC3339)
-	}
-	if !d.CreationTimestamp.IsZero() {
-		resp.CreatedAt = d.CreationTimestamp.UTC().Format("2006-01-02 15:04:05 UTC")
-	}
-	return resp
-}
-
-// ——————————————————————————————————————————
-// MQTT Auth — Этап 2
-// ——————————————————————————————————————————
-
-// MQTTAuth — POST /internal/mqtt/auth
-// Вызывается EMQX при каждом MQTT CONNECT.
-// НЕ защищён JWT middleware — доступен только из кластера (путь /internal/).
-//
-// Логика аутентификации:
-//   1. Распарсить username → namespace + deviceId
-//   2. Получить Secret iot-{deviceId} в namespace
-//   3. Constant-time сравнение пароля (защита от timing attacks)
-//   4. Проверить что IoTDevice существует и enabled=true
-//   5. Обновить status.lastConnected в IoTDevice
-func (h *Handler) MQTTAuth(w http.ResponseWriter, r *http.Request) {
-	var req mqttAuthRequest
-	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
-		// Плохой JSON от EMQX — deny, но не 400 (EMQX игнорирует non-200)
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-
-	// Парсим username: "{namespace}_{deviceId}"
-	// Namespace содержит только [a-z0-9-], первый "_" — разделитель.
-	idx := strings.Index(req.Username, "_")
-	if idx < 0 {
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-	ns := req.Username[:idx]
-	deviceID := req.Username[idx+1:]
-	if ns == "" || deviceID == "" {
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-
-	// Читаем Secret с MQTT credentials
-	secretName := "iot-" + deviceID
-	secret := &corev1.Secret{}
-	if err := h.K8s.Get(r.Context(), client.ObjectKey{Namespace: ns, Name: secretName}, secret); err != nil {
-		// Secret не найден или ошибка k8s — deny
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-
-	// Constant-time сравнение пароля — защита от timing attacks
-	storedPassword := secret.Data["mqtt-password"]
-	if subtle.ConstantTimeCompare(storedPassword, []byte(req.Password)) != 1 {
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-
-	// Проверяем что IoTDevice активно
-	device := &iotv1alpha1.IoTDevice{}
-	if err := h.K8s.Get(r.Context(), client.ObjectKey{Namespace: ns, Name: deviceID}, device); err != nil {
-		// IoTDevice не найден (или удалён) — deny
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-	if !device.Spec.Enabled {
-		writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "deny"})
-		return
-	}
-
-	// Обновляем lastConnected в статусе устройства (best-effort, ошибка не критична)
-	now := metav1.NewTime(time.Now().UTC())
-	device.Status.LastConnected = &now
-	if err := h.K8s.Status().Update(r.Context(), device); err != nil {
-		h.Log.Warn("mqtt auth: failed to update lastConnected", "device", deviceID, "err", err)
-		// Продолжаем — это некритично, устройство всё равно авторизовано
-	}
-
-	// Проверки пройдены — разрешаем подключение
-	writeJSON(w, http.StatusOK, mqttAuthResponse{Result: "allow"})
-}
-
-// ——————————————————————————————————————————
-// IoT Device CRUD — Этап 4
-// ——————————————————————————————————————————
-
-// CreateIoTDevice — POST /v1/namespaces/{namespace}/iot/devices
-// Создаёт IoTDevice CRD. Контроллер асинхронно сгенерирует MQTT credentials.
-// credentials доступны через GET /devices/{name} после reconcile (phase=Active).
-func (h *Handler) CreateIoTDevice(w http.ResponseWriter, r *http.Request) {
-	ns := namespace(r)
-	var req iotDeviceCreateRequest
-	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
-		writeJSON(w, http.StatusBadRequest, errResp("invalid JSON: "+err.Error()))
-		return
-	}
-	if req.Name == "" {
-		writeJSON(w, http.StatusBadRequest, errResp("name is required"))
-		return
-	}
-	if req.DeviceID == "" {
-		writeJSON(w, http.StatusBadRequest, errResp("device_id is required"))
-		return
-	}
-
-	enabled := true
-	if req.Enabled != nil {
-		enabled = *req.Enabled
-	}
-
-	device := &iotv1alpha1.IoTDevice{
-		ObjectMeta: metav1.ObjectMeta{
-			Name:      req.Name,
-			Namespace: ns,
-		},
-		Spec: iotv1alpha1.IoTDeviceSpec{
-			DeviceID: req.DeviceID,
-			Enabled:  enabled,
-			Metadata: req.Metadata,
-		},
-	}
-
-	if err := h.K8s.Create(r.Context(), device); err != nil {
-		if errors.IsAlreadyExists(err) {
-			writeJSON(w, http.StatusConflict, errResp("iot device already exists"))
-			return
-		}
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-
-	writeJSON(w, http.StatusCreated, deviceToResponse(device, ""))
-}
-
-// ListIoTDevices — GET /v1/namespaces/{namespace}/iot/devices
-// Возвращает список устройств БЕЗ паролей (security by design).
-func (h *Handler) ListIoTDevices(w http.ResponseWriter, r *http.Request) {
-	ns := namespace(r)
-	list := &iotv1alpha1.IoTDeviceList{}
-	if err := h.K8s.List(r.Context(), list, client.InNamespace(ns)); err != nil {
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-	result := make([]iotDeviceResponse, 0, len(list.Items))
-	for i := range list.Items {
-		result = append(result, deviceToResponse(&list.Items[i], ""))
-	}
-	writeJSON(w, http.StatusOK, result)
-}
-
-// GetIoTDevice — GET /v1/namespaces/{namespace}/iot/devices/{name}
-// Возвращает устройство включая mqtt_password из Secret.
-// mqtt_password нужен пользователю для конфигурации физического устройства.
-func (h *Handler) GetIoTDevice(w http.ResponseWriter, r *http.Request) {
-	ns := namespace(r)
-	name := pathVar(r, "name")
-
-	device := &iotv1alpha1.IoTDevice{}
-	if err := h.K8s.Get(r.Context(), client.ObjectKey{Namespace: ns, Name: name}, device); err != nil {
-		if errors.IsNotFound(err) {
-			writeJSON(w, http.StatusNotFound, errResp("iot device not found"))
-			return
-		}
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-
-	// Читаем пароль из Secret — если ещё не создан (phase=Pending), password будет пустым
-	password := ""
-	if device.Status.SecretName != "" {
-		secret := &corev1.Secret{}
-		err := h.K8s.Get(r.Context(), client.ObjectKey{Namespace: ns, Name: device.Status.SecretName}, secret)
-		if err == nil {
-			password = string(secret.Data["mqtt-password"])
-		}
-		// Если Secret не найден — просто передаём пустой пароль (устройство ещё provisioning)
-	}
-
-	writeJSON(w, http.StatusOK, deviceToResponse(device, password))
-}
-
-// DeleteIoTDevice — DELETE /v1/namespaces/{namespace}/iot/devices/{name}
-// Удаляет IoTDevice CRD. Контроллер через finalizer удалит Secret каскадно.
-func (h *Handler) DeleteIoTDevice(w http.ResponseWriter, r *http.Request) {
-	ns := namespace(r)
-	name := pathVar(r, "name")
-
-	device := &iotv1alpha1.IoTDevice{}
-	if err := h.K8s.Get(r.Context(), client.ObjectKey{Namespace: ns, Name: name}, device); err != nil {
-		if errors.IsNotFound(err) {
-			writeJSON(w, http.StatusNotFound, errResp("iot device not found"))
-			return
-		}
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-
-	if err := h.K8s.Delete(r.Context(), device); err != nil {
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-
-	w.WriteHeader(http.StatusNoContent)
-}
-
-// UpdateIoTDevice — PATCH /v1/namespaces/{namespace}/iot/devices/{name}
-// Позволяет включить/отключить устройство (spec.enabled).
-// Контроллер увидит изменение и обновит status.phase.
-func (h *Handler) UpdateIoTDevice(w http.ResponseWriter, r *http.Request) {
-	ns := namespace(r)
-	name := pathVar(r, "name")
-
-	var req iotDeviceUpdateRequest
-	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
-		writeJSON(w, http.StatusBadRequest, errResp("invalid JSON: "+err.Error()))
-		return
-	}
-	if req.Enabled == nil {
-		writeJSON(w, http.StatusBadRequest, errResp("enabled field is required"))
-		return
-	}
-
-	device := &iotv1alpha1.IoTDevice{}
-	if err := h.K8s.Get(r.Context(), client.ObjectKey{Namespace: ns, Name: name}, device); err != nil {
-		if errors.IsNotFound(err) {
-			writeJSON(w, http.StatusNotFound, errResp("iot device not found"))
-			return
-		}
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-
-	device.Spec.Enabled = *req.Enabled
-	if err := h.K8s.Update(r.Context(), device); err != nil {
-		writeJSON(w, http.StatusInternalServerError, errResp(err.Error()))
-		return
-	}
-
-	writeJSON(w, http.StatusOK, deviceToResponse(device, ""))
-}

internal/api/router.go

@@ -70,17 +70,6 @@ func NewRouter(h *handler.Handler, log *slog.Logger) http.Handler {
 	v1.HandleFunc("/namespaces/{namespace}/jobs/{name}", h.DeleteJob).Methods(http.MethodDelete)
 	v1.HandleFunc("/namespaces/{namespace}/jobs/{name}/upload", h.UploadJobCode).Methods(http.MethodPost)
 
-	// IoT Devices CRUD — защищены JWT (как все /v1/ маршруты)
-	v1.HandleFunc("/namespaces/{namespace}/iot/devices", h.ListIoTDevices).Methods(http.MethodGet)
-	v1.HandleFunc("/namespaces/{namespace}/iot/devices", h.CreateIoTDevice).Methods(http.MethodPost)
-	v1.HandleFunc("/namespaces/{namespace}/iot/devices/{name}", h.GetIoTDevice).Methods(http.MethodGet)
-	v1.HandleFunc("/namespaces/{namespace}/iot/devices/{name}", h.DeleteIoTDevice).Methods(http.MethodDelete)
-	v1.HandleFunc("/namespaces/{namespace}/iot/devices/{name}", h.UpdateIoTDevice).Methods(http.MethodPatch)
-
-	// MQTT Auth — БЕЗ JWT. Вызывается EMQX при MQTT CONNECT из кластера.
-	// /internal/ недоступен снаружи (Ingress не проксирует /internal/).
-	r.HandleFunc("/internal/mqtt/auth", h.MQTTAuth).Methods(http.MethodPost)
-
 	// Цепочка middleware: logging → (auth только для /v1/) → router
 	// /fn/ — без auth, /v1/ — с auth.
 	// Используем gorilla/mux Use() чтобы auth применялся только к v1 суброутеру.

iot/api/v1alpha1/device_types.go

@@ -1,99 +0,0 @@
-// Создано: 2026-04-04
-// Описание CRD IoTDevice — регистрация IoT-устройства в платформе sless.
-// Пользователь создаёт IoTDevice, контроллер автоматически генерирует MQTT-credentials
-// и сохраняет их в k8s Secret в том же namespace.
-// При удалении IoTDevice — Secret удаляется каскадно через OwnerReference.
-
-package v1alpha1
-
-import (
-	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
-)
-
-// IoTDeviceSpec — желаемое состояние IoT-устройства.
-type IoTDeviceSpec struct {
-	// DeviceID — уникальный идентификатор устройства внутри namespace.
-	// Используется как часть MQTT username и имени Secret.
-	// Разрешены только строчные буквы, цифры и дефис — для совместимости с k8s именами.
-	// +kubebuilder:validation:Required
-	// +kubebuilder:validation:Pattern=`^[a-z0-9][a-z0-9-]*[a-z0-9]$`
-	// +kubebuilder:validation:MaxLength=48
-	DeviceID string `json:"deviceId"`
-
-	// Metadata — произвольные метаданные устройства (модель, локация и т.д.).
-	// Хранятся только в CRD, не влияют на логику контроллера.
-	// +optional
-	Metadata map[string]string `json:"metadata,omitempty"`
-
-	// Enabled — активно ли устройство (может подключаться к MQTT).
-	// Если false — контроллер устанавливает phase=Disabled, EMQX auth отклоняет подключение.
-	// Secret с credentials НЕ удаляется — при re-enable пароль остаётся прежним.
-	// +kubebuilder:default=true
-	Enabled bool `json:"enabled"`
-}
-
-// IoTDevicePhase — текущая фаза жизненного цикла устройства.
-type IoTDevicePhase string
-
-const (
-	// IoTDevicePhaseActive — устройство активно, credentials выданы, может подключаться к MQTT.
-	IoTDevicePhaseActive IoTDevicePhase = "Active"
-	// IoTDevicePhaseDisabled — устройство отключено (spec.enabled=false). EMQX отклоняет подключения.
-	IoTDevicePhaseDisabled IoTDevicePhase = "Disabled"
-	// IoTDevicePhasePending — устройство создано, контроллер ещё не успел сгенерировать credentials.
-	IoTDevicePhasePending IoTDevicePhase = "Pending"
-	// IoTDevicePhaseError — ошибка при создании credentials (см. status.message).
-	IoTDevicePhaseError IoTDevicePhase = "Error"
-)
-
-// IoTDeviceStatus — наблюдаемое состояние IoT-устройства (заполняет контроллер).
-type IoTDeviceStatus struct {
-	// Phase — текущее состояние: Active, Disabled, Pending, Error.
-	Phase IoTDevicePhase `json:"phase,omitempty"`
-
-	// MQTTUsername — имя пользователя для подключения к MQTT-брокеру.
-	// Формат: {namespace}_{deviceId} — глобально уникален в рамках EMQX.
-	MQTTUsername string `json:"mqttUsername,omitempty"`
-
-	// SecretName — имя k8s Secret в том же namespace, содержащего mqtt-username и mqtt-password.
-	SecretName string `json:"secretName,omitempty"`
-
-	// TopicPrefix — MQTT topic prefix, на который разрешена публикация.
-	// Формат: {namespace}/ — устройство не может публиковать в чужие namespace.
-	TopicPrefix string `json:"topicPrefix,omitempty"`
-
-	// LastConnected — время последнего MQTT-подключения устройства.
-	// Заполняется MQTT auth-сервисом при каждом успешном CONNECT.
-	// +optional
-	LastConnected *metav1.Time `json:"lastConnected,omitempty"`
-
-	// Message — человекочитаемое сообщение о текущем статусе или ошибке.
-	Message string `json:"message,omitempty"`
-}
-
-// +kubebuilder:object:root=true
-// +kubebuilder:subresource:status
-// +kubebuilder:printcolumn:name="DeviceID",type=string,JSONPath=`.spec.deviceId`
-// +kubebuilder:printcolumn:name="Phase",type=string,JSONPath=`.status.phase`
-// +kubebuilder:printcolumn:name="Enabled",type=boolean,JSONPath=`.spec.enabled`
-// +kubebuilder:printcolumn:name="MQTTUser",type=string,JSONPath=`.status.mqttUsername`
-// +kubebuilder:printcolumn:name="Age",type=date,JSONPath=`.metadata.creationTimestamp`
-
-// IoTDevice — ресурс для регистрации IoT-устройства в платформе.
-// Контроллер автоматически создаёт k8s Secret с MQTT-credentials.
-type IoTDevice struct {
-	metav1.TypeMeta   `json:",inline"`
-	metav1.ObjectMeta `json:"metadata,omitempty"`
-
-	Spec   IoTDeviceSpec   `json:"spec,omitempty"`
-	Status IoTDeviceStatus `json:"status,omitempty"`
-}
-
-// +kubebuilder:object:root=true
-
-// IoTDeviceList — список IoTDevice объектов.
-type IoTDeviceList struct {
-	metav1.TypeMeta `json:",inline"`
-	metav1.ListMeta `json:"metadata,omitempty"`
-	Items           []IoTDevice `json:"items"`
-}

iot/api/v1alpha1/groupversion_info.go

@@ -1,30 +0,0 @@
-// Создано: 2026-04-04
-// groupversion_info.go — регистрация API group iot.kube5s.ru/v1alpha1.
-// ВАЖНО: группа намеренно отдельная от sless.kube5s.ru — при выносе IoT в
-// отдельную репу CRD не будет конфликтовать с sless CRD.
-
-// Package v1alpha1 содержит API Schema definitions для группы iot.kube5s.ru.
-// +kubebuilder:object:generate=true
-// +groupName=iot.kube5s.ru
-package v1alpha1
-
-import (
-	"k8s.io/apimachinery/pkg/runtime/schema"
-	"sigs.k8s.io/controller-runtime/pkg/scheme"
-)
-
-var (
-	// GroupVersion — API group/version для IoT ресурсов.
-	// Отдельный от sless.kube5s.ru — для изоляции и будущего разделения репозиториев.
-	GroupVersion = schema.GroupVersion{Group: "iot.kube5s.ru", Version: "v1alpha1"}
-
-	// SchemeBuilder регистрирует Go-типы в GroupVersionKind scheme.
-	SchemeBuilder = &scheme.Builder{GroupVersion: GroupVersion}
-
-	// AddToScheme добавляет типы этой API группы в scheme manager'а.
-	AddToScheme = SchemeBuilder.AddToScheme
-)
-
-func init() {
-	SchemeBuilder.Register(&IoTDevice{}, &IoTDeviceList{})
-}

iot/api/v1alpha1/zz_generated.deepcopy.go

@@ -1,109 +0,0 @@
-//go:build !ignore_autogenerated
-
-// Code generated by controller-gen. DO NOT EDIT.
-
-package v1alpha1
-
-import (
-	runtime "k8s.io/apimachinery/pkg/runtime"
-)
-
-// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
-func (in *IoTDevice) DeepCopyInto(out *IoTDevice) {
-	*out = *in
-	out.TypeMeta = in.TypeMeta
-	in.ObjectMeta.DeepCopyInto(&out.ObjectMeta)
-	in.Spec.DeepCopyInto(&out.Spec)
-	in.Status.DeepCopyInto(&out.Status)
-}
-
-// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new IoTDevice.
-func (in *IoTDevice) DeepCopy() *IoTDevice {
-	if in == nil {
-		return nil
-	}
-	out := new(IoTDevice)
-	in.DeepCopyInto(out)
-	return out
-}
-
-// DeepCopyObject is an autogenerated deepcopy function, copying the receiver, creating a new runtime.Object.
-func (in *IoTDevice) DeepCopyObject() runtime.Object {
-	if c := in.DeepCopy(); c != nil {
-		return c
-	}
-	return nil
-}
-
-// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
-func (in *IoTDeviceList) DeepCopyInto(out *IoTDeviceList) {
-	*out = *in
-	out.TypeMeta = in.TypeMeta
-	in.ListMeta.DeepCopyInto(&out.ListMeta)
-	if in.Items != nil {
-		in, out := &in.Items, &out.Items
-		*out = make([]IoTDevice, len(*in))
-		for i := range *in {
-			(*in)[i].DeepCopyInto(&(*out)[i])
-		}
-	}
-}
-
-// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new IoTDeviceList.
-func (in *IoTDeviceList) DeepCopy() *IoTDeviceList {
-	if in == nil {
-		return nil
-	}
-	out := new(IoTDeviceList)
-	in.DeepCopyInto(out)
-	return out
-}
-
-// DeepCopyObject is an autogenerated deepcopy function, copying the receiver, creating a new runtime.Object.
-func (in *IoTDeviceList) DeepCopyObject() runtime.Object {
-	if c := in.DeepCopy(); c != nil {
-		return c
-	}
-	return nil
-}
-
-// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
-func (in *IoTDeviceSpec) DeepCopyInto(out *IoTDeviceSpec) {
-	*out = *in
-	if in.Metadata != nil {
-		in, out := &in.Metadata, &out.Metadata
-		*out = make(map[string]string, len(*in))
-		for key, val := range *in {
-			(*out)[key] = val
-		}
-	}
-}
-
-// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new IoTDeviceSpec.
-func (in *IoTDeviceSpec) DeepCopy() *IoTDeviceSpec {
-	if in == nil {
-		return nil
-	}
-	out := new(IoTDeviceSpec)
-	in.DeepCopyInto(out)
-	return out
-}
-
-// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
-func (in *IoTDeviceStatus) DeepCopyInto(out *IoTDeviceStatus) {
-	*out = *in
-	if in.LastConnected != nil {
-		in, out := &in.LastConnected, &out.LastConnected
-		*out = (*in).DeepCopy()
-	}
-}
-
-// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new IoTDeviceStatus.
-func (in *IoTDeviceStatus) DeepCopy() *IoTDeviceStatus {
-	if in == nil {
-		return nil
-	}
-	out := new(IoTDeviceStatus)
-	in.DeepCopyInto(out)
-	return out
-}

iot/cmd/mqtt-bridge/main.go

@@ -1,271 +0,0 @@
-// Создано: 2026-04-04
-// mqtt-bridge/main.go — сервис-мост: MQTT (EMQX) → RabbitMQ.
-//
-// Роль в архитектуре:
-//   IoT Device → MQTT PUBLISH → EMQX → [mqtt-bridge подписан на "+/telemetry/+"] → RabbitMQ → event-dispatcher → function
-//
-// Логика:
-//   1. Подключиться к EMQX как MQTT клиент (credentials из env)
-//   2. Подписаться на топик "+/telemetry/+" (any namespace / telemetry / any device)
-//   3. При получении сообщения:
-//      - Извлечь namespace из топика — первый сегмент до "/"
-//      - Опубликовать в RabbitMQ queue "iot.{namespace}.telemetry"
-//      - Payload передаётся as-is (JSON от устройства)
-//   4. Переподключаться к RabbitMQ при разрыве (reconnect loop)
-//
-// Конфигурация через env vars:
-//   MQTT_BROKER_URL — tcp://emqx.sless.svc:1883
-//   MQTT_USERNAME   — username для подключения bridge к EMQX
-//   MQTT_PASSWORD   — пароль bridge клиента
-//   RABBITMQ_URL    — amqp://sless:sless123@rabbitmq.sless.svc.cluster.local:5672/
-//
-// ВАЖНО: bridge клиент должен проходить EMQX auth — нужен IoTDevice "iot-bridge" в namespace "sless-bridge".
-// Для MVP: выделить специальный namespace "sless-bridge" с устройством "bridge",
-// и использовать его credentials для подключения bridge сервиса.
-// Или: зарегистрировать bridge устройство через API и записать credentials в Secret.
-
-package main
-
-import (
-	"context"
-	"encoding/json"
-	"fmt"
-	"log/slog"
-	"os"
-	"os/signal"
-	"strings"
-	"syscall"
-	"time"
-
-	mqtt "github.com/eclipse/paho.mqtt.golang"
-	amqp "github.com/rabbitmq/amqp091-go"
-)
-
-// mqttBridgeConfig — конфигурация сервиса из env vars.
-type mqttBridgeConfig struct {
-	MQTTBrokerURL string
-	MQTTUsername  string
-	MQTTPassword  string
-	RabbitMQURL   string
-}
-
-// iotTelemetryMessage — структура сообщения публикуемого в RabbitMQ.
-// Оборачивает MQTT payload в envelope с метаданными.
-type iotTelemetryMessage struct {
-	// Namespace — k8s namespace пользователя (из MQTT topic)
-	Namespace string `json:"namespace"`
-	// DeviceID — идентификатор устройства (из MQTT topic, последний сегмент)
-	DeviceID string `json:"device_id"`
-	// Topic — оригинальный MQTT topic
-	Topic string `json:"topic"`
-	// Payload — данные от устройства (JSON передаётся as-is / строка если не JSON)
-	Payload json.RawMessage `json:"payload"`
-	// ReceivedAt — время получения сообщения мостом (UTC)
-	ReceivedAt string `json:"received_at"`
-}
-
-func main() {
-	log := slog.New(slog.NewTextHandler(os.Stdout, &slog.HandlerOptions{Level: slog.LevelInfo}))
-
-	cfg := loadBridgeConfig()
-
-	ctx, cancel := signal.NotifyContext(context.Background(), syscall.SIGTERM, syscall.SIGINT)
-	defer cancel()
-
-	log.Info("starting iot-mqtt-bridge",
-		"mqtt_broker", cfg.MQTTBrokerURL,
-		"mqtt_username", cfg.MQTTUsername,
-	)
-
-	// RabbitMQ connection с reconnect loop
-	rabbitConn, err := connectRabbitMQWithRetry(ctx, cfg.RabbitMQURL, log)
-	if err != nil {
-		log.Error("failed to connect to RabbitMQ", "err", err)
-		os.Exit(1)
-	}
-	defer rabbitConn.Close()
-
-	rabbitCh, err := rabbitConn.Channel()
-	if err != nil {
-		log.Error("failed to open RabbitMQ channel", "err", err)
-		os.Exit(1)
-	}
-	defer rabbitCh.Close()
-
-	// Создаём MQTT клиент
-	mqttClient, err := connectMQTT(cfg, log)
-	if err != nil {
-		log.Error("failed to connect to MQTT broker", "err", err)
-		os.Exit(1)
-	}
-	defer mqttClient.Disconnect(500)
-
-	// Функция-обработчик MQTT сообщений
-	// Вызывается в goroutine paho при каждом сообщении
-	messageHandler := buildMQTTMessageHandler(rabbitCh, log)
-
-	// Подписываемся на все telemetry топики всех namespace
-	// "+/telemetry/+" = {любой namespace}/telemetry/{любой deviceId}
-	const telemetryTopicFilter = "+/telemetry/+"
-	token := mqttClient.Subscribe(telemetryTopicFilter, 1, messageHandler)
-	token.Wait()
-	if token.Error() != nil {
-		log.Error("mqtt subscribe failed", "topic", telemetryTopicFilter, "err", token.Error())
-		os.Exit(1)
-	}
-	log.Info("subscribed to MQTT topic", "filter", telemetryTopicFilter)
-
-	<-ctx.Done()
-	log.Info("shutting down iot-mqtt-bridge")
-}
-
-// loadBridgeConfig читает конфигурацию из env vars.
-// Завершает процесс если обязательные переменные отсутствуют.
-func loadBridgeConfig() mqttBridgeConfig {
-	required := func(key string) string {
-		v := os.Getenv(key)
-		if v == "" {
-			slog.Error("required env var not set", "key", key)
-			os.Exit(1)
-		}
-		return v
-	}
-
-	return mqttBridgeConfig{
-		MQTTBrokerURL: getEnvOrDefault("MQTT_BROKER_URL", "tcp://emqx.sless.svc:1883"),
-		MQTTUsername:  required("MQTT_USERNAME"),
-		MQTTPassword:  required("MQTT_PASSWORD"),
-		RabbitMQURL:   required("RABBITMQ_URL"),
-	}
-}
-
-func getEnvOrDefault(key, defaultVal string) string {
-	if v := os.Getenv(key); v != "" {
-		return v
-	}
-	return defaultVal
-}
-
-// connectMQTT устанавливает подключение к EMQX брокеру.
-// AutoReconnect=true — paho сам переподключается при разрыве.
-func connectMQTT(cfg mqttBridgeConfig, log *slog.Logger) (mqtt.Client, error) {
-	opts := mqtt.NewClientOptions()
-	opts.AddBroker(cfg.MQTTBrokerURL)
-	opts.SetClientID("sless-iot-bridge")
-	opts.SetUsername(cfg.MQTTUsername)
-	opts.SetPassword(cfg.MQTTPassword)
-	opts.SetAutoReconnect(true)
-	opts.SetConnectRetry(true)
-	opts.SetConnectRetryInterval(5 * time.Second)
-	opts.SetKeepAlive(30 * time.Second)
-	opts.SetCleanSession(false) // сохраняем подписки при реконнекте
-
-	opts.SetConnectionLostHandler(func(_ mqtt.Client, err error) {
-		log.Warn("MQTT connection lost, reconnecting...", "err", err)
-	})
-	opts.SetReconnectingHandler(func(_ mqtt.Client, _ *mqtt.ClientOptions) {
-		log.Info("MQTT reconnecting...")
-	})
-	opts.SetOnConnectHandler(func(_ mqtt.Client) {
-		log.Info("MQTT connected to broker")
-	})
-
-	client := mqtt.NewClient(opts)
-	token := client.Connect()
-	// Ждём максимум 30 секунд
-	if !token.WaitTimeout(30 * time.Second) {
-		return nil, fmt.Errorf("MQTT connect timeout")
-	}
-	if token.Error() != nil {
-		return nil, fmt.Errorf("MQTT connect: %w", token.Error())
-	}
-	return client, nil
-}
-
-// connectRabbitMQWithRetry подключается к RabbitMQ с повторными попытками.
-// Retry нужен потому что RabbitMQ может стартовать позже bridge сервиса.
-func connectRabbitMQWithRetry(ctx context.Context, url string, log *slog.Logger) (*amqp.Connection, error) {
-	const maxAttempts = 10
-	for attempt := 1; attempt <= maxAttempts; attempt++ {
-		conn, err := amqp.Dial(url)
-		if err == nil {
-			log.Info("connected to RabbitMQ", "attempt", attempt)
-			return conn, nil
-		}
-		log.Warn("RabbitMQ connection failed, retrying...", "attempt", attempt, "err", err)
-		select {
-		case <-ctx.Done():
-			return nil, ctx.Err()
-		case <-time.After(5 * time.Second):
-		}
-	}
-	return nil, fmt.Errorf("exhausted %d RabbitMQ connection attempts", maxAttempts)
-}
-
-// buildMQTTMessageHandler возвращает функцию-обработчик MQTT сообщений.
-// Замыкание над rabbitCh (RabbitMQ channel) и logger.
-func buildMQTTMessageHandler(rabbitCh *amqp.Channel, log *slog.Logger) mqtt.MessageHandler {
-	return func(_ mqtt.Client, msg mqtt.Message) {
-		topic := msg.Topic()
-		payload := msg.Payload()
-
-		// Топик: "{namespace}/telemetry/{deviceId}"
-		// Извлекаем namespace (первый сегмент) и deviceId (третий сегмент)
-		parts := strings.SplitN(topic, "/", 3)
-		if len(parts) != 3 {
-			log.Warn("unexpected MQTT topic format, skipping", "topic", topic)
-			return
-		}
-		ns := parts[0]
-		deviceID := parts[2]
-
-		// Формируем envelope — оборачиваем payload в JSON с метаданными
-		// Payload от устройства может быть любым JSON или строкой
-		rawPayload := json.RawMessage(payload)
-		if !json.Valid(payload) {
-			// Если payload не JSON — упаковываем в строку
-			quotedBytes, _ := json.Marshal(string(payload))
-			rawPayload = json.RawMessage(quotedBytes)
-		}
-
-		envelope := iotTelemetryMessage{
-			Namespace:  ns,
-			DeviceID:   deviceID,
-			Topic:      topic,
-			Payload:    rawPayload,
-			ReceivedAt: time.Now().UTC().Format(time.RFC3339),
-		}
-
-		body, err := json.Marshal(envelope)
-		if err != nil {
-			log.Error("marshal telemetry message", "topic", topic, "err", err)
-			return
-		}
-
-		// Queue name: "iot.{namespace}.telemetry"
-		// Declare-on-publish: если queue не существует — создаём
-		queueName := fmt.Sprintf("iot.%s.telemetry", ns)
-		if _, err := rabbitCh.QueueDeclare(queueName, true, false, false, false, nil); err != nil {
-			log.Error("declare RabbitMQ queue", "queue", queueName, "err", err)
-			return
-		}
-
-		err = rabbitCh.Publish(
-			"",        // exchange — default exchange
-			queueName, // routing key = queue name для default exchange
-			false,     // mandatory
-			false,     // immediate
-			amqp.Publishing{
-				ContentType:  "application/json",
-				Body:         body,
-				DeliveryMode: amqp.Persistent, // сохранять при рестарте RabbitMQ
-			},
-		)
-		if err != nil {
-			log.Error("publish to RabbitMQ", "queue", queueName, "err", err)
-			return
-		}
-
-		log.Info("forwarded IoT telemetry", "topic", topic, "namespace", ns, "device", deviceID, "queue", queueName)
-	}
-}

iot/config/crd/bases/iot.kube5s.ru_iotdevices.yaml

@@ -1,123 +0,0 @@
----
-apiVersion: apiextensions.k8s.io/v1
-kind: CustomResourceDefinition
-metadata:
-  annotations:
-    controller-gen.kubebuilder.io/version: v0.14.0
-  name: iotdevices.iot.kube5s.ru
-spec:
-  group: iot.kube5s.ru
-  names:
-    kind: IoTDevice
-    listKind: IoTDeviceList
-    plural: iotdevices
-    singular: iotdevice
-  scope: Namespaced
-  versions:
-  - additionalPrinterColumns:
-    - jsonPath: .spec.deviceId
-      name: DeviceID
-      type: string
-    - jsonPath: .status.phase
-      name: Phase
-      type: string
-    - jsonPath: .spec.enabled
-      name: Enabled
-      type: boolean
-    - jsonPath: .status.mqttUsername
-      name: MQTTUser
-      type: string
-    - jsonPath: .metadata.creationTimestamp
-      name: Age
-      type: date
-    name: v1alpha1
-    schema:
-      openAPIV3Schema:
-        description: |-
-          IoTDevice — ресурс для регистрации IoT-устройства в платформе.
-          Контроллер автоматически создаёт k8s Secret с MQTT-credentials.
-        properties:
-          apiVersion:
-            description: |-
-              APIVersion defines the versioned schema of this representation of an object.
-              Servers should convert recognized schemas to the latest internal value, and
-              may reject unrecognized values.
-              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
-            type: string
-          kind:
-            description: |-
-              Kind is a string value representing the REST resource this object represents.
-              Servers may infer this from the endpoint the client submits requests to.
-              Cannot be updated.
-              In CamelCase.
-              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
-            type: string
-          metadata:
-            type: object
-          spec:
-            description: IoTDeviceSpec — желаемое состояние IoT-устройства.
-            properties:
-              deviceId:
-                description: |-
-                  DeviceID — уникальный идентификатор устройства внутри namespace.
-                  Используется как часть MQTT username и имени Secret.
-                  Разрешены только строчные буквы, цифры и дефис — для совместимости с k8s именами.
-                maxLength: 48
-                pattern: ^[a-z0-9][a-z0-9-]*[a-z0-9]$
-                type: string
-              enabled:
-                default: true
-                description: |-
-                  Enabled — активно ли устройство (может подключаться к MQTT).
-                  Если false — контроллер устанавливает phase=Disabled, EMQX auth отклоняет подключение.
-                  Secret с credentials НЕ удаляется — при re-enable пароль остаётся прежним.
-                type: boolean
-              metadata:
-                additionalProperties:
-                  type: string
-                description: |-
-                  Metadata — произвольные метаданные устройства (модель, локация и т.д.).
-                  Хранятся только в CRD, не влияют на логику контроллера.
-                type: object
-            required:
-            - deviceId
-            - enabled
-            type: object
-          status:
-            description: IoTDeviceStatus — наблюдаемое состояние IoT-устройства (заполняет
-              контроллер).
-            properties:
-              lastConnected:
-                description: |-
-                  LastConnected — время последнего MQTT-подключения устройства.
-                  Заполняется MQTT auth-сервисом при каждом успешном CONNECT.
-                format: date-time
-                type: string
-              message:
-                description: Message — человекочитаемое сообщение о текущем статусе
-                  или ошибке.
-                type: string
-              mqttUsername:
-                description: |-
-                  MQTTUsername — имя пользователя для подключения к MQTT-брокеру.
-                  Формат: {namespace}_{deviceId} — глобально уникален в рамках EMQX.
-                type: string
-              phase:
-                description: 'Phase — текущее состояние: Active, Disabled, Pending,
-                  Error.'
-                type: string
-              secretName:
-                description: SecretName — имя k8s Secret в том же namespace, содержащего
-                  mqtt-username и mqtt-password.
-                type: string
-              topicPrefix:
-                description: |-
-                  TopicPrefix — MQTT topic prefix, на который разрешена публикация.
-                  Формат: {namespace}/ — устройство не может публиковать в чужие namespace.
-                type: string
-            type: object
-        type: object
-    served: true
-    storage: true
-    subresources:
-      status: {}

iot/controllers/iotdevice_controller.go

@@ -1,175 +0,0 @@
-// Создано: 2026-04-04
-// iotdevice_controller.go — контроллер IoTDevice CRD.
-// Логика Reconcile:
-//   1. Добавить finalizer при первом создании
-//   2. При удалении (DeletionTimestamp != nil) — убрать finalizer.
-//      Secret удалится автоматически по OwnerReference (cascade GC).
-//   3. Если spec.enabled=false — установить phase=Disabled, не создавать Secret.
-//      Если Secret уже существует — НЕ удалять (при re-enable пароль сохранится).
-//   4. Если Secret не существует — сгенерировать пароль, создать Secret с OwnerRef.
-//   5. Обновить status: phase, mqttUsername, secretName, topicPrefix.
-
-package controllers
-
-import (
-	"context"
-	"crypto/rand"
-	"encoding/hex"
-	"fmt"
-
-	corev1 "k8s.io/api/core/v1"
-	"k8s.io/apimachinery/pkg/api/errors"
-	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
-	"k8s.io/apimachinery/pkg/runtime"
-	ctrl "sigs.k8s.io/controller-runtime"
-	"sigs.k8s.io/controller-runtime/pkg/client"
-	"sigs.k8s.io/controller-runtime/pkg/controller/controllerutil"
-	"sigs.k8s.io/controller-runtime/pkg/log"
-
-	iotv1alpha1 "gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/api/v1alpha1"
-)
-
-// iotDeviceFinalizer — имя finalizer для IoTDevice.
-// Гарантирует что контроллер обработает удаление до того как k8s удалит объект.
-const iotDeviceFinalizer = "iot.kube5s.ru/device-cleanup"
-
-// IoTDeviceReconciler управляет жизненным циклом IoTDevice CRD.
-type IoTDeviceReconciler struct {
-	client.Client
-	Scheme *runtime.Scheme
-}
-
-// +kubebuilder:rbac:groups=iot.kube5s.ru,resources=iotdevices,verbs=get;list;watch;create;update;patch;delete
-// +kubebuilder:rbac:groups=iot.kube5s.ru,resources=iotdevices/status,verbs=get;update;patch
-// +kubebuilder:rbac:groups=iot.kube5s.ru,resources=iotdevices/finalizers,verbs=update
-// +kubebuilder:rbac:groups="",resources=secrets,verbs=get;list;watch;create;delete
-
-// Reconcile — главный цикл управления IoTDevice.
-func (r *IoTDeviceReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
-	logger := log.FromContext(ctx)
-
-	// Читаем IoTDevice из k8s
-	device := &iotv1alpha1.IoTDevice{}
-	if err := r.Get(ctx, req.NamespacedName, device); err != nil {
-		if errors.IsNotFound(err) {
-			// Объект удалён — финализация уже завершена
-			return ctrl.Result{}, nil
-		}
-		return ctrl.Result{}, fmt.Errorf("get iotdevice: %w", err)
-	}
-
-	// Если объект помечен к удалению — убираем finalizer.
-	// Secret удалится каскадно через OwnerReference — явно удалять не нужно.
-	if !device.DeletionTimestamp.IsZero() {
-		if controllerutil.ContainsFinalizer(device, iotDeviceFinalizer) {
-			controllerutil.RemoveFinalizer(device, iotDeviceFinalizer)
-			if err := r.Update(ctx, device); err != nil {
-				return ctrl.Result{}, fmt.Errorf("remove finalizer: %w", err)
-			}
-			logger.Info("removed finalizer from IoTDevice", "device", req.Name)
-		}
-		return ctrl.Result{}, nil
-	}
-
-	// Добавляем finalizer при первом создании объекта
-	if !controllerutil.ContainsFinalizer(device, iotDeviceFinalizer) {
-		controllerutil.AddFinalizer(device, iotDeviceFinalizer)
-		if err := r.Update(ctx, device); err != nil {
-			return ctrl.Result{}, fmt.Errorf("add finalizer: %w", err)
-		}
-		// Requeue — обязательно, чтобы продолжить reconcile с обновлённым объектом
-		return ctrl.Result{Requeue: true}, nil
-	}
-
-	// Если устройство отключено — обновляем статус, не создаём Secret
-	if !device.Spec.Enabled {
-		return ctrl.Result{}, r.setStatus(ctx, device, iotv1alpha1.IoTDevicePhaseDisabled, "Device is disabled")
-	}
-
-	// Имя Secret и MQTT username по формату из плана
-	secretName := "iot-" + device.Spec.DeviceID
-	mqttUsername := fmt.Sprintf("%s_%s", device.Namespace, device.Spec.DeviceID)
-
-	// Проверяем наличие Secret — если нет, создаём с новыми credentials
-	existingSecret := &corev1.Secret{}
-	err := r.Get(ctx, client.ObjectKey{Namespace: device.Namespace, Name: secretName}, existingSecret)
-	if errors.IsNotFound(err) {
-		// Генерируем криптографически стойкий пароль: 32 байта = 64 hex символа
-		password, genErr := generateMQTTPassword()
-		if genErr != nil {
-			setErr := r.setStatus(ctx, device, iotv1alpha1.IoTDevicePhaseError, fmt.Sprintf("generate password: %v", genErr))
-			return ctrl.Result{}, setErr
-		}
-
-		secret := &corev1.Secret{
-			ObjectMeta: metav1.ObjectMeta{
-				Name:      secretName,
-				Namespace: device.Namespace,
-			},
-			Data: map[string][]byte{
-				"mqtt-username": []byte(mqttUsername),
-				"mqtt-password": []byte(password),
-			},
-		}
-
-		// OwnerReference — Secret принадлежит IoTDevice.
-		// При удалении IoTDevice k8s каскадно удалит Secret.
-		if ownerErr := controllerutil.SetControllerReference(device, secret, r.Scheme); ownerErr != nil {
-			return ctrl.Result{}, fmt.Errorf("set owner reference: %w", ownerErr)
-		}
-
-		if createErr := r.Create(ctx, secret); createErr != nil {
-			setErr := r.setStatus(ctx, device, iotv1alpha1.IoTDevicePhaseError, fmt.Sprintf("create secret: %v", createErr))
-			return ctrl.Result{}, setErr
-		}
-		logger.Info("created MQTT credentials Secret", "secret", secretName, "device", device.Spec.DeviceID)
-
-	} else if err != nil {
-		// Неожиданная ошибка при чтении Secret
-		return ctrl.Result{}, fmt.Errorf("get secret: %w", err)
-	}
-	// else — Secret уже существует, ничего не делаем (пароль не меняем)
-
-	// Обновляем status — отражаем актуальное состояние устройства
-	device.Status.Phase = iotv1alpha1.IoTDevicePhaseActive
-	device.Status.MQTTUsername = mqttUsername
-	device.Status.SecretName = secretName
-	device.Status.TopicPrefix = device.Namespace + "/"
-	device.Status.Message = ""
-
-	if statusErr := r.Status().Update(ctx, device); statusErr != nil {
-		return ctrl.Result{}, fmt.Errorf("update status: %w", statusErr)
-	}
-
-	return ctrl.Result{}, nil
-}
-
-// setStatus — вспомогательная функция для обновления status.Phase и status.Message.
-// Используется для промежуточных состояний (Disabled, Error).
-func (r *IoTDeviceReconciler) setStatus(ctx context.Context, device *iotv1alpha1.IoTDevice, phase iotv1alpha1.IoTDevicePhase, message string) error {
-	device.Status.Phase = phase
-	device.Status.Message = message
-	if err := r.Status().Update(ctx, device); err != nil {
-		return fmt.Errorf("update status to %s: %w", phase, err)
-	}
-	return nil
-}
-
-// generateMQTTPassword генерирует криптографически стойкий пароль для MQTT.
-// 32 байта случайных данных → hex строка 64 символа = 256 бит энтропии.
-func generateMQTTPassword() (string, error) {
-	buf := make([]byte, 32)
-	if _, err := rand.Read(buf); err != nil {
-		return "", fmt.Errorf("rand.Read: %w", err)
-	}
-	return hex.EncodeToString(buf), nil
-}
-
-// SetupWithManager регистрирует контроллер в manager'е.
-// Watches только IoTDevice — secrets обновляются через reconcile loop при необходимости.
-func (r *IoTDeviceReconciler) SetupWithManager(mgr ctrl.Manager) error {
-	return ctrl.NewControllerManagedBy(mgr).
-		For(&iotv1alpha1.IoTDevice{}).
-		Owns(&corev1.Secret{}).
-		Complete(r)
-}

main.go

@@ -27,8 +27,6 @@ import (
 
 	slessv1alpha1 "gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/api/v1alpha1"
 	"gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/controllers"
-	iotv1alpha1 "gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/api/v1alpha1"
-	iotcontrollers "gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/iot/controllers"
 	slessapi "gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/internal/api"
 	"gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/internal/api/handler"
 	"gitea-naeel.giteak8s.services.ngcloud.ru/naeel/sless/internal/builder"
@@ -47,8 +45,6 @@ func init() {
 	utilruntime.Must(clientgoscheme.AddToScheme(scheme))
 
 	utilruntime.Must(slessv1alpha1.AddToScheme(scheme))
-	// IoT API group iot.kube5s.ru/v1alpha1 — отдельная схема для IoT-ресурсов
-	utilruntime.Must(iotv1alpha1.AddToScheme(scheme))
 	//+kubebuilder:scaffold:scheme
 }
 
@@ -194,14 +190,6 @@ func main() {
 		log.Error("unable to create controller", "controller", "FunctionJob", "err", err)
 		os.Exit(1)
 	}
-	// IoTDevice контроллер — управляет MQTT credentials для IoT-устройств
-	if err = (&iotcontrollers.IoTDeviceReconciler{
-		Client: mgr.GetClient(),
-		Scheme: mgr.GetScheme(),
-	}).SetupWithManager(mgr); err != nil {
-		log.Error("unable to create controller", "controller", "IoTDevice", "err", err)
-		os.Exit(1)
-	}
 	//+kubebuilder:scaffold:builder
 
 	if err := mgr.AddHealthzCheck("healthz", healthz.Ping); err != nil {

runtimes/nodejs20/server.js

@@ -1,5 +1,4 @@
 // Изменено: 2026-03-09
-// Изменено: 2026-04-10 (v0.1.3) — sendResult: если handler вернул строку начинающуюся с '<' → text/html.
 // HTTP-обёртка для serverless функций на Node.js 20.
 // Загружает модуль из SLESS_ENTRYPOINT или handler.js по умолчанию.
 // Формат SLESS_ENTRYPOINT: "module-name.functionName" (например: handler-http.handle)
@@ -66,7 +65,7 @@ const server = http.createServer(async (req, res) => {
 
         try {
             const result = await userHandle(event);
-            sendResult(res, 200, result);
+            sendJSON(res, 200, result);
         } catch (err) {
             console.error('Handler error:', err);
             sendJSON(res, 500, { error: err.message });
@@ -74,21 +73,6 @@ const server = http.createServer(async (req, res) => {
     });
 });
 
-function sendResult(res, status, data) {
-    // Если handler вернул строку начинающуюся с '<' — HTML страница.
-    // Если строка, но не HTML — text/plain. Иначе — JSON.
-    if (typeof data === 'string') {
-        const ctype = data.trimStart().startsWith('<')
-            ? 'text/html; charset=utf-8'
-            : 'text/plain; charset=utf-8';
-        const buf = Buffer.from(data, 'utf-8');
-        res.writeHead(status, { 'Content-Type': ctype, 'Content-Length': buf.length });
-        res.end(buf);
-        return;
-    }
-    sendJSON(res, status, data);
-}
-
 function sendJSON(res, status, data) {
     const body = JSON.stringify(data);
     res.writeHead(status, {

terraform/provider/internal/client/client.go

@@ -522,138 +522,6 @@ func (c *Client) DeleteJob(ctx context.Context, ns, name string) error {
 	return nil
 }
 
-// --- IoTDevice CRUD ---
-// Изменено: 2026-04-04
-
-// IoTDeviceRequest — тело POST /v1/namespaces/{ns}/iot/devices
-type IoTDeviceRequest struct {
-	Name     string            `json:"name"`
-	DeviceID string            `json:"device_id"`
-	Enabled  *bool             `json:"enabled"`
-	Metadata map[string]string `json:"metadata,omitempty"`
-}
-
-// IoTDeviceUpdateRequest — тело PATCH /v1/namespaces/{ns}/iot/devices/{name}
-type IoTDeviceUpdateRequest struct {
-	Enabled *bool `json:"enabled"`
-}
-
-// IoTDeviceResponse — ответ GET /v1/namespaces/{ns}/iot/devices/{name}
-// mqtt_password заполняется только если устройство в фазе Active.
-type IoTDeviceResponse struct {
-	Name          string            `json:"name"`
-	Namespace     string            `json:"namespace"`
-	DeviceID      string            `json:"device_id"`
-	Enabled       bool              `json:"enabled"`
-	Phase         string            `json:"phase"`
-	MQTTUsername  string            `json:"mqtt_username"`
-	MQTTPassword  string            `json:"mqtt_password"`
-	SecretName    string            `json:"secret_name"`
-	TopicPrefix   string            `json:"topic_prefix"`
-	LastConnected string            `json:"last_connected,omitempty"`
-	Message       string            `json:"message,omitempty"`
-	Metadata      map[string]string `json:"metadata,omitempty"`
-	CreatedAt     string            `json:"created_at,omitempty"`
-}
-
-// CreateIoTDevice — POST /v1/namespaces/{ns}/iot/devices → 201
-func (c *Client) CreateIoTDevice(ctx context.Context, ns string, req IoTDeviceRequest) (*IoTDeviceResponse, error) {
-	url := fmt.Sprintf("%s/v1/namespaces/%s/iot/devices", c.endpoint, ns)
-	resp, err := c.doJSON(ctx, http.MethodPost, url, req)
-	if err != nil {
-		return nil, err
-	}
-	defer resp.Body.Close()
-	if resp.StatusCode != http.StatusCreated {
-		body, _ := io.ReadAll(resp.Body)
-		return nil, fmt.Errorf("create iot device: status %d: %s", resp.StatusCode, body)
-	}
-	var d IoTDeviceResponse
-	return &d, json.NewDecoder(resp.Body).Decode(&d)
-}
-
-// GetIoTDevice — GET /v1/namespaces/{ns}/iot/devices/{name} → nil если 404
-// Возвращает mqtt_password из Secret. После создания ждать phase=Active.
-func (c *Client) GetIoTDevice(ctx context.Context, ns, name string) (*IoTDeviceResponse, error) {
-	url := fmt.Sprintf("%s/v1/namespaces/%s/iot/devices/%s", c.endpoint, ns, name)
-	resp, err := c.doJSON(ctx, http.MethodGet, url, nil)
-	if err != nil {
-		return nil, err
-	}
-	defer resp.Body.Close()
-	if resp.StatusCode == http.StatusNotFound {
-		return nil, nil
-	}
-	if resp.StatusCode != http.StatusOK {
-		body, _ := io.ReadAll(resp.Body)
-		return nil, fmt.Errorf("get iot device: status %d: %s", resp.StatusCode, body)
-	}
-	var d IoTDeviceResponse
-	return &d, json.NewDecoder(resp.Body).Decode(&d)
-}
-
-// DeleteIoTDevice — DELETE /v1/namespaces/{ns}/iot/devices/{name} → 204
-func (c *Client) DeleteIoTDevice(ctx context.Context, ns, name string) error {
-	url := fmt.Sprintf("%s/v1/namespaces/%s/iot/devices/%s", c.endpoint, ns, name)
-	resp, err := c.doJSON(ctx, http.MethodDelete, url, nil)
-	if err != nil {
-		return err
-	}
-	defer resp.Body.Close()
-	if resp.StatusCode != http.StatusNoContent && resp.StatusCode != http.StatusNotFound {
-		body, _ := io.ReadAll(resp.Body)
-		return fmt.Errorf("delete iot device: status %d: %s", resp.StatusCode, body)
-	}
-	return nil
-}
-
-// UpdateIoTDevice — PATCH /v1/namespaces/{ns}/iot/devices/{name} → 200
-// Позволяет изменить enabled без пересоздания устройства.
-func (c *Client) UpdateIoTDevice(ctx context.Context, ns, name string, req IoTDeviceUpdateRequest) (*IoTDeviceResponse, error) {
-	url := fmt.Sprintf("%s/v1/namespaces/%s/iot/devices/%s", c.endpoint, ns, name)
-	resp, err := c.doJSON(ctx, http.MethodPatch, url, req)
-	if err != nil {
-		return nil, err
-	}
-	defer resp.Body.Close()
-	if resp.StatusCode != http.StatusOK {
-		body, _ := io.ReadAll(resp.Body)
-		return nil, fmt.Errorf("update iot device: status %d: %s", resp.StatusCode, body)
-	}
-	var d IoTDeviceResponse
-	return &d, json.NewDecoder(resp.Body).Decode(&d)
-}
-
-// WaitIoTDeviceActive опрашивает устройство каждые 2 секунды пока phase != Active/Error/Disabled.
-// Нужен после CreateIoTDevice — контроллер асинхронно создаёт Secret с credentials.
-func (c *Client) WaitIoTDeviceActive(ctx context.Context, ns, name string, timeout time.Duration) (*IoTDeviceResponse, error) {
-	deadline := time.Now().Add(timeout)
-	for time.Now().Before(deadline) {
-		d, err := c.GetIoTDevice(ctx, ns, name)
-		if err != nil {
-			return nil, err
-		}
-		if d == nil {
-			return nil, fmt.Errorf("iot device %s/%s not found while waiting", ns, name)
-		}
-		switch d.Phase {
-		case "Active":
-			return d, nil
-		case "Error":
-			return nil, fmt.Errorf("iot device provisioning failed: %s", d.Message)
-		case "Disabled":
-			// enabled=false при создании — credentials не создаются, это ожидаемо
-			return d, nil
-		}
-		select {
-		case <-ctx.Done():
-			return nil, ctx.Err()
-		case <-time.After(2 * time.Second):
-		}
-	}
-	return nil, fmt.Errorf("timeout waiting for iot device %s/%s to become Active", ns, name)
-}
-
 // EnsureNamespace — POST /v1/namespaces/{ns}/ensure
 // Создаёт k8s namespace пользователя если не существует. Идемпотентен.
 // Вызывается ОДИН РАЗ из provider.Configure() до любых ресурсных операций.

terraform/provider/internal/provider/provider.go

@@ -170,7 +170,6 @@ func (p *SlessProvider) Resources(_ context.Context) []func() resource.Resource
 		resources.NewServiceResource,
 		resources.NewTriggerResource,
 		resources.NewJobResource,
-		resources.NewIoTDeviceResource,
 	}
 }
 

terraform/provider/internal/resources/iot_device_resource.go

@@ -1,254 +0,0 @@
-// Создано: 2026-04-04
-// iot_device_resource.go — Terraform ресурс sless_iot_device.
-//
-// Lifecycle:
-//   Create: POST /iot/devices → WaitIoTDeviceActive (30 сек) → сохранить credentials в state
-//   Read:   GET  /iot/devices/{name} → sync state (включая mqtt_password)
-//   Update: PATCH /iot/devices/{name} → только enabled (in-place, без пересоздания)
-//   Delete: DELETE /iot/devices/{name} → контроллер каскадно удалит Secret
-//
-// mqtt_password — sensitive, хранится в terraform state.
-// Это осознанное решение: credentials нужны для конфигурации физического устройства.
-// Пользователь их получает через terraform output.
-//
-// device_id — RequiresReplace: изменение deviceId = другое устройство (другой Secret, другой username).
-// name — RequiresReplace: имя k8s объекта нельзя изменить.
-
-package resources
-
-import (
-	"context"
-	"fmt"
-	"time"
-
-	"terraform-provider-sless/internal/client"
-
-	"github.com/hashicorp/terraform-plugin-framework/resource"
-	"github.com/hashicorp/terraform-plugin-framework/resource/schema"
-	"github.com/hashicorp/terraform-plugin-framework/resource/schema/booldefault"
-	"github.com/hashicorp/terraform-plugin-framework/resource/schema/planmodifier"
-	"github.com/hashicorp/terraform-plugin-framework/resource/schema/stringplanmodifier"
-	"github.com/hashicorp/terraform-plugin-framework/types"
-)
-
-// defaultIoTWaitSec — таймаут ожидания provisioning credentials контроллером.
-const defaultIoTWaitSec = 30 * time.Second
-
-var _ resource.Resource = &IoTDeviceResource{}
-
-// IoTDeviceResource — Terraform ресурс sless_iot_device.
-type IoTDeviceResource struct {
-	client *client.Client
-}
-
-func NewIoTDeviceResource() resource.Resource {
-	return &IoTDeviceResource{}
-}
-
-// IoTDeviceModel — модель terraform state для sless_iot_device.
-type IoTDeviceModel struct {
-	Name         types.String `tfsdk:"name"`
-	DeviceID     types.String `tfsdk:"device_id"`
-	Enabled      types.Bool   `tfsdk:"enabled"`
-	Metadata     types.Map    `tfsdk:"metadata"`
-	Phase        types.String `tfsdk:"phase"`
-	MQTTUsername types.String `tfsdk:"mqtt_username"`
-	// mqtt_password — sensitive: не отображается в terraform plan/apply output.
-	// Хранится в state (зашифрованном) — единственный способ передать в устройство.
-	MQTTPassword types.String `tfsdk:"mqtt_password"`
-	TopicPrefix  types.String `tfsdk:"topic_prefix"`
-}
-
-func (r *IoTDeviceResource) Metadata(_ context.Context, req resource.MetadataRequest, resp *resource.MetadataResponse) {
-	resp.TypeName = req.ProviderTypeName + "_iot_device"
-}
-
-func (r *IoTDeviceResource) Schema(_ context.Context, _ resource.SchemaRequest, resp *resource.SchemaResponse) {
-	resp.Schema = schema.Schema{
-		MarkdownDescription: "IoT устройство в платформе sless. Контроллер автоматически генерирует MQTT credentials.",
-		Attributes: map[string]schema.Attribute{
-			// name — имя k8s объекта IoTDevice (уникальное в namespace)
-			"name": schema.StringAttribute{
-				Required: true,
-				PlanModifiers: []planmodifier.String{
-					stringplanmodifier.RequiresReplace(),
-				},
-			},
-			// device_id — идентификатор устройства. Используется в MQTT username: {namespace}_{device_id}
-			// Только [a-z0-9-] — совпадает с валидацией в CRD (+kubebuilder:validation:Pattern).
-			"device_id": schema.StringAttribute{
-				Required: true,
-				PlanModifiers: []planmodifier.String{
-					stringplanmodifier.RequiresReplace(),
-				},
-			},
-			// enabled — включить/отключить MQTT подключения. in-place через PATCH.
-			"enabled": schema.BoolAttribute{
-				Optional: true,
-				Computed: true,
-				Default:  booldefault.StaticBool(true),
-			},
-			// metadata — произвольные метаданные (модель устройства, локация и т.д.)
-			"metadata": schema.MapAttribute{
-				ElementType: types.StringType,
-				Optional:    true,
-				Computed:    true,
-			},
-			// Computed — заполняются оператором после прохождения reconcile
-			"phase": schema.StringAttribute{
-				Computed: true,
-				PlanModifiers: []planmodifier.String{
-					stringplanmodifier.UseStateForUnknown(),
-				},
-			},
-			"mqtt_username": schema.StringAttribute{
-				Computed: true,
-				PlanModifiers: []planmodifier.String{
-					stringplanmodifier.UseStateForUnknown(),
-				},
-			},
-			// mqtt_password — sensitive because it is a secret credential.
-			// Хранится в terraform state. Доступен через: terraform output -raw mqtt_password
-			"mqtt_password": schema.StringAttribute{
-				Computed:  true,
-				Sensitive: true,
-				PlanModifiers: []planmodifier.String{
-					stringplanmodifier.UseStateForUnknown(),
-				},
-			},
-			"topic_prefix": schema.StringAttribute{
-				Computed: true,
-				PlanModifiers: []planmodifier.String{
-					stringplanmodifier.UseStateForUnknown(),
-				},
-			},
-		},
-	}
-}
-
-func (r *IoTDeviceResource) Configure(_ context.Context, req resource.ConfigureRequest, resp *resource.ConfigureResponse) {
-	if req.ProviderData == nil {
-		return
-	}
-	c, ok := req.ProviderData.(*client.Client)
-	if !ok {
-		resp.Diagnostics.AddError(
-			"unexpected provider data",
-			fmt.Sprintf("expected *client.Client, got: %T", req.ProviderData),
-		)
-		return
-	}
-	r.client = c
-}
-
-func (r *IoTDeviceResource) Create(ctx context.Context, req resource.CreateRequest, resp *resource.CreateResponse) {
-	var plan IoTDeviceModel
-	resp.Diagnostics.Append(req.Plan.Get(ctx, &plan)...)
-	if resp.Diagnostics.HasError() {
-		return
-	}
-
-	// Конвертируем metadata из types.Map в map[string]string
-	metadata := make(map[string]string)
-	if !plan.Metadata.IsNull() && !plan.Metadata.IsUnknown() {
-		resp.Diagnostics.Append(plan.Metadata.ElementsAs(ctx, &metadata, false)...)
-		if resp.Diagnostics.HasError() {
-			return
-		}
-	}
-
-	enabled := plan.Enabled.ValueBool()
-	_, err := r.client.CreateIoTDevice(ctx, r.client.Namespace, client.IoTDeviceRequest{
-		Name:     plan.Name.ValueString(),
-		DeviceID: plan.DeviceID.ValueString(),
-		Enabled:  &enabled,
-		Metadata: metadata,
-	})
-	if err != nil {
-		resp.Diagnostics.AddError("create iot device", err.Error())
-		return
-	}
-
-	// Ждём пока контроллер сгенерирует MQTT credentials (phase=Active).
-	// Без ожидания mqtt_password будет пустым в state — terraform output выдаст "".
-	d, err := r.client.WaitIoTDeviceActive(ctx, r.client.Namespace, plan.Name.ValueString(), defaultIoTWaitSec)
-	if err != nil {
-		resp.Diagnostics.AddError("wait iot device active", err.Error())
-		return
-	}
-
-	resp.Diagnostics.Append(resp.State.Set(ctx, deviceToModel(d))...)
-}
-
-func (r *IoTDeviceResource) Read(ctx context.Context, req resource.ReadRequest, resp *resource.ReadResponse) {
-	var state IoTDeviceModel
-	resp.Diagnostics.Append(req.State.Get(ctx, &state)...)
-	if resp.Diagnostics.HasError() {
-		return
-	}
-
-	d, err := r.client.GetIoTDevice(ctx, r.client.Namespace, state.Name.ValueString())
-	if err != nil {
-		resp.Diagnostics.AddError("read iot device", err.Error())
-		return
-	}
-	if d == nil {
-		resp.State.RemoveResource(ctx)
-		return
-	}
-
-	resp.Diagnostics.Append(resp.State.Set(ctx, deviceToModel(d))...)
-}
-
-// Update — изменяет только enabled (единственное поле без RequiresReplace).
-func (r *IoTDeviceResource) Update(ctx context.Context, req resource.UpdateRequest, resp *resource.UpdateResponse) {
-	var plan IoTDeviceModel
-	resp.Diagnostics.Append(req.Plan.Get(ctx, &plan)...)
-	if resp.Diagnostics.HasError() {
-		return
-	}
-
-	enabled := plan.Enabled.ValueBool()
-	d, err := r.client.UpdateIoTDevice(ctx, r.client.Namespace, plan.Name.ValueString(), client.IoTDeviceUpdateRequest{
-		Enabled: &enabled,
-	})
-	if err != nil {
-		resp.Diagnostics.AddError("update iot device", err.Error())
-		return
-	}
-
-	resp.Diagnostics.Append(resp.State.Set(ctx, deviceToModel(d))...)
-}
-
-func (r *IoTDeviceResource) Delete(ctx context.Context, req resource.DeleteRequest, resp *resource.DeleteResponse) {
-	var state IoTDeviceModel
-	resp.Diagnostics.Append(req.State.Get(ctx, &state)...)
-	if resp.Diagnostics.HasError() {
-		return
-	}
-
-	if err := r.client.DeleteIoTDevice(ctx, r.client.Namespace, state.Name.ValueString()); err != nil {
-		resp.Diagnostics.AddError("delete iot device", err.Error())
-		return
-	}
-}
-
-// deviceToModel конвертирует API ответ в terraform state модель.
-func deviceToModel(d *client.IoTDeviceResponse) IoTDeviceModel {
-	metadataMap := make(map[string]string)
-	if d.Metadata != nil {
-		metadataMap = d.Metadata
-	}
-	metadataValue, _ := types.MapValueFrom(context.Background(), types.StringType, metadataMap)
-
-	return IoTDeviceModel{
-		Name:         types.StringValue(d.Name),
-		DeviceID:     types.StringValue(d.DeviceID),
-		Enabled:      types.BoolValue(d.Enabled),
-		Metadata:     metadataValue,
-		Phase:        types.StringValue(d.Phase),
-		MQTTUsername: types.StringValue(d.MQTTUsername),
-		MQTTPassword: types.StringValue(d.MQTTPassword),
-		TopicPrefix:  types.StringValue(d.TopicPrefix),
-	}
-}

terraform/provider/main.go

@@ -1,4 +1,4 @@
-// 2026-04-04 — добавлен ресурс sless_iot_device
+// 2026-03-07
 // main.go — точка входа Terraform провайдера sless.
 // Address: terra.k8c.ru/naeel/sless — путь в реестре terra.k8c.ru.
 package main
@@ -12,8 +12,8 @@ import (
 	"github.com/hashicorp/terraform-plugin-framework/providerserver"
 )
 
-// version задаётся ldflags при сборке: -ldflags "-X main.version=0.1.2"
-var version string = "0.1.2"
+// version задаётся ldflags при сборке: -ldflags "-X main.version=0.1.1"
+var version string = "0.1.1"
 
 func main() {
 	opts := providerserver.ServeOpts{