fix: v0.1.50 — runtime 400 + SLESS_ENTRYPOINT в Deployment
Bug 1: services.go — k8s IsInvalid error (CRD enum validation) маппился в 500. Теперь errors.IsInvalid() → 400 Bad Request (invalid service spec). Bug 2: service_controller.go buildServiceDeployment не передавал env SLESS_ENTRYPOINT в под. Добавлен в envVars из svc.Spec.Entrypoint. Без него server.py использовал fallback handler.handle и не замечал неверный entrypoint. operator_failure_test.sh 12B-2: обновлён под новое правильное поведение — create ruby3.0 → 400 (не 201). Старый 201-путь сохранён как warn для совместимости.
This commit is contained in:
Naeel
@@ -2,6 +2,25 @@
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-21 — Оценка трудозатрат на проект
|
||||
|
||||
| Компонент | Оценка |
|
||||
|-----------|--------|
|
||||
| Go operator — CRD (Function, Trigger, Job), 3 контроллера, reconcile loops, self-healing | 80-100 ч |
|
||||
| REST API — router, middleware, 8 handlers, namespace lifecycle | 40-50 ч |
|
||||
| Terraform провайдер — provider, client, 4 ресурса | 40-60 ч |
|
||||
| Builder — kaniko, S3 upload, context tar | 20-30 ч |
|
||||
| Runtimes — Go/Node/Python базовые образы | 20-30 ч |
|
||||
| Инфраструктура — k8s manifests, kustomize, Harbor, Postgres | 20-30 ч |
|
||||
| Тесты — lifecycle (47) + survival (34), ~1900 строк bash | 40-60 ч |
|
||||
| Документация — architecture, decisions, errors, API, handoffs | 20-30 ч |
|
||||
|
||||
**Итого: ~280-390 человеко-часов** (7-10 недель одного разработчика в нормальном темпе).
|
||||
|
||||
С AI-ассистентом в паре реальное живое время ~80-120 часов (30-50% от полного объёма).
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-21 — timeout_sec для sless_service: 0 = нет лимита (не 30s по умолчанию)
|
||||
|
||||
### Контекст
|
||||
|
||||
+57
-1
@@ -1,6 +1,62 @@
|
||||
# Прогресс разработки
|
||||
|
||||
Последнее обновление: 2026-03-21 (operator v0.1.49 — оба бага исправлены; lifecycle-тест 47/47 PASS)
|
||||
Последнее обновление: 2026-03-21
|
||||
|
||||
---
|
||||
|
||||
## TODO (backlog — не скоро)
|
||||
|
||||
| # | Задача | Заметка |
|
||||
|---|--------|---------|
|
||||
| T1 | `nubes_endpoint` в sless провайдере — сделать обязательным или ввести флаг `require_token_validation` | Сейчас если `nubes_endpoint` не задан — проверка токена через nubes API пропускается. Упущение безопасности. |
|
||||
| T2 | **Terraform провайдер nubes — end-to-end тестирование** | Провайдер написан но ни разу не прогонялся с реальным сервером. Нужно: `init → apply → apply (idempotency) → update → destroy`. Тест-кейсы уже есть в `examples/`. Это отдельный большой блок работы для облачных DevOps-инженеров nubes. |
|
||||
|
||||
---
|
||||
|
||||
## TODO (завтра — приоритет)
|
||||
|
||||
### ПЛАН: multi-user тест с Postgres
|
||||
|
||||
**Шаг 1 — Добавить Postgres в survival тест (один юзер):**
|
||||
- Функции в `operator_survival_test.sh` сейчас echo-хендлеры без PG
|
||||
- Добавить группу тестов где функция делает реальные INSERT/SELECT в Postgres
|
||||
- Postgres креды берутся из параметров ресурса `sless_pg` (через `env_vars` функции)
|
||||
- Изоляция: таблица называется `test_<namespace>` — каждый юзер пишет в свою
|
||||
- Прогнать от одного юзера → убедиться что работает
|
||||
|
||||
**Шаг 2 — Параметризовать survival тест:**
|
||||
- `TOKEN` и `NAMESPACE` через env переменные (сейчас хардкодные)
|
||||
- `PG_DSN` через env переменную (берётся из параметров Postgres ресурса)
|
||||
|
||||
**Шаг 3 — Обёртка на 10 юзеров:**
|
||||
- `operator_multiuser_test.sh`
|
||||
- Генерирует 10 фейковых JWT (`test-user-01` ... `test-user-10`)
|
||||
- Для каждого вычисляет namespace (SHA256(sub)[:8 байт])
|
||||
- `POST /v1/namespaces/{ns}/ensure` — создаёт namespace
|
||||
- Параллельно запускает полный survival тест в каждом namespace (`&`)
|
||||
- Ждёт всех (`wait`), собирает итоговый отчёт: PASS/FAIL по каждому юзеру
|
||||
|
||||
**Ожидаемый результат:** ~340 тестов (34×10), ~15-20 минут параллельно
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-21 — Сессия 7: survival-тест (группы 5-10)
|
||||
|
||||
### Что сделано
|
||||
|
||||
| # | Компонент | Результат |
|
||||
|---|-----------|-----------|
|
||||
| 1 | `operator_survival_test.sh` — написан (928 строк, 6 групп) | ✅ запущен |
|
||||
| 2 | Группа 5: FLOOD BUILD — 6 функций (3×Python + 3×Node.js), 9 тестов | 🔄 в процессе |
|
||||
| 3 | Группа 6: RAPID DISCARD STORM — 30 create→DELETE, 4 теста | 🔄 в процессе |
|
||||
| 4 | Группа 7: CHURN UNDER FIRE — 10 PUT под 200 invokes, 9 тестов | 🔄 в процессе |
|
||||
| 5 | Группа 8: PHOENIX — 3 цикла DELETE+recreate | 🔄 в процессе |
|
||||
| 6 | Группа 9: SELF-HEALING MARATHON — 5×kill Deployment | 🔄 в процессе |
|
||||
| 7 | Группа 10: INVOKE HURRICANE — 500 parallel invokes | 🔄 в процессе |
|
||||
|
||||
Лог: VM `/tmp/survival.log`, ожидаемое время: ~75-100 мин
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user