fix(vm_stress_test): make read-only workflow, add instructions and docs
This commit is contained in:
Naeel
@@ -2,6 +2,70 @@
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-30 — Переход на READ-ONLY подход в тестах (v2)
|
||||
|
||||
### Решение
|
||||
Полностью переписан `vm_stress_test.sh`. Убраны все функции записи в файлы
|
||||
(`write_tfvars`, `backup_tfvars`, `restore_tfvars`). Переопределения переменных
|
||||
теперь через `-var` в terraform CLI. Добавлена проверка md5sum terraform.tfvars.
|
||||
|
||||
### Почему
|
||||
Функция `write_tfvars()` в v1 уничтожила `terraform.tfvars`, потеряв JWT-токен
|
||||
`api_token`. Пайплайн `grep | cut | xargs | sed` не смог корректно обработать
|
||||
JWT строку длиной 1200+ символов. Восстановление потребовало ручного вмешательства.
|
||||
|
||||
### Ключевые принципы v2:
|
||||
- Скрипт **НИКОГДА** не пишет в файлы (read-only)
|
||||
- Все переопределения — через `terraform apply -var "key=value"`
|
||||
- md5sum проверка после каждой фазы, аварийный стоп при изменении
|
||||
- `terraform.tfvars` содержит секреты (api_token) → нельзя трогать
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-30 — Автономный тестовый фреймворк для VM
|
||||
|
||||
### Решение
|
||||
Внедрить bash-скрипт `vm_stress_test.sh` как основной инструмент для долгого, самовосстанавливающегося тестирования примера `examples/VM`.
|
||||
|
||||
### Почему
|
||||
- Предыдущие ручные тесты подтвердили корректность логики, но для выявления редких race conditions и обеспечения преемственности между разными сессиями агентов нужен воспроизводимый сценарий.
|
||||
- Скрипт инкапсулирует все "знания" о VM (IP, ключи, логика очистки `apt`), позволяя любому агенту запустить тест одной командой.
|
||||
- Использование `timeout` на уровне команд `terraform` и `ssh` внутри скрипта предотвращает зависание автоматизации.
|
||||
|
||||
## 2026-03-29 — Матрица тестов VM example подтверждена прогоном
|
||||
|
||||
### Решение
|
||||
|
||||
Оставить текущую модель тестирования [examples/VM](examples/VM) как комбинацию из ручного cleanup, destroy/apply цикла, частичного отключения job-ресурсов и короткого stress loop.
|
||||
|
||||
### Почему
|
||||
|
||||
- Эта матрица проверяет и lifecycle VM, и идемпотентность job-ресурсов, и реакцию на изменение количества/порядка установок.
|
||||
- Отдельный destroy/apply прогон подтвердил suspend/wake поведение без необходимости писать новый тестовый фреймворк.
|
||||
- Stress loop из двух циклов дал полезную нагрузку без чрезмерного времени прогона.
|
||||
|
||||
## 2026-03-29 — Матрица тестов для VM example
|
||||
|
||||
### Решение
|
||||
|
||||
Для проверки поведения [examples/VM](examples/VM) использовать не один прогон, а набор сценариев:
|
||||
|
||||
1. обычный `apply` как базовый контроль;
|
||||
2. удаление всего установленного ПО внутри ВМ перед `destroy`;
|
||||
3. `destroy` с проверкой перехода ВМ в `suspend`;
|
||||
4. повторный `apply` с проверкой wake-up и повторной установки;
|
||||
5. изменение количества и порядка установок;
|
||||
6. стресс-прогоны с несколькими повторениями.
|
||||
|
||||
### Почему так
|
||||
|
||||
- Один проход не показывает идемпотентность и не ловит проблемы порядка ресурсов.
|
||||
- Сценарий с `destroy` проверяет, что инфраструктура не удаляет ВМ физически, а переводит её в `suspend`.
|
||||
- Повторный `apply` после `suspend` проверяет восстановление состояния без ручного вмешательства.
|
||||
- Перестановки и изменение количества установок нужны, чтобы проверить устойчивость к дрейфу и к разным графам зависимостей.
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-21 — Оценка трудозатрат на проект
|
||||
|
||||
| Компонент | Оценка |
|
||||
|
||||
+87
-58
@@ -1,9 +1,95 @@
|
||||
# Прогресс разработки
|
||||
|
||||
Последнее обновление: 2026-03-23
|
||||
Последнее обновление: 2026-03-30
|
||||
|
||||
---
|
||||
|
||||
## 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)
|
||||
|
||||
### Контекст и цель
|
||||
@@ -1417,60 +1503,3 @@ G15 перезапущен → **21/21 PASS ✅**
|
||||
### Версия оператора
|
||||
`v0.1.51` — задеплоен, работает
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Шаг 6: VM provisioning через sless_job (2026-03-29)
|
||||
|
||||
### Цель
|
||||
Установить пакеты, nginx и docker на свежую Nubes VM через sless_job.
|
||||
|
||||
### Что реализовано
|
||||
- `examples/VM/sless.tf` — три `sless_job` ресурса с `depends_on` цепочкой:
|
||||
- `vm-install-packages` → jq, python3-pip, htop, unzip
|
||||
- `vm-install-nginx` → nginx (depends_on install-packages)
|
||||
- `vm-install-docker` → Docker CE 29.3.1 + Compose v5.1.1 (depends_on install-nginx)
|
||||
- `examples/VM/variables.tf` — переменная `install_run_id` для управления rebuildом
|
||||
|
||||
---
|
||||
|
||||
## Шаг 6: VM provisioning через sless_job (2026-03-29)
|
||||
|
||||
### Цель
|
||||
Установить пакеты, nginx и docker на свежую Nubes VM через sless_job.
|
||||
|
||||
### Что реализовано
|
||||
- `examples/VM/sless.tf` — три `sless_job` ресурса с `depends_on` цепочкой:
|
||||
- `vm-install-packages` → jq, python3-pip, htop, unzip
|
||||
- `vm-install-nginx` → nginx (depends_on install-packages)
|
||||
- `vm-install-docker` → Docker CE 29.3.1 + Compose v5.1.1 (depends_on install-nginx)
|
||||
- `examples/VM/variables.tf` — переменная `install_run_id` для управления rebuild'ом
|
||||
- `examples/VM/outputs.tf` — вывод результатов job'ов
|
||||
- `examples/VM/functions/install-packages/handler.py` — SSH установка пакетов
|
||||
- `examples/VM/functions/install-nginx/handler.py` — SSH установка nginx
|
||||
- `examples/VM/functions/install-docker/handler.py` — SSH установка Docker CE
|
||||
|
||||
### Баги найдены и исправлены
|
||||
|
||||
#### Баг 1: Ubuntu 22.04 — cloud-init держит apt lock при старте VM
|
||||
- **Симптом**: `E: Could not get lock /var/lib/dpkg/lock-frontend (held by process 2191)`
|
||||
- **Причина**: `unattended-upgrades` держит lock через cloud-init 15-20 мин после старта VM
|
||||
- **Фикс**: `_wait_apt_lock()` начинает с `cloud-init status --wait` (timeout 300s), затем `systemctl mask` сервисов авто-обновления
|
||||
|
||||
#### Баг 2: Оператор запускает СТАРЫЙ образ после upload
|
||||
- **Симптом**: `image already exists in registry, skipping build` — новый код не применялся
|
||||
- **Причина**: Go DEFLATE создавал идентичные байты zip для разных версий handler.py, sha256(zip) не менялся
|
||||
- **Фикс**: изменение requirements.txt гарантирует уникальный zip hash
|
||||
|
||||
#### Баг 3: WaitJobDone мгновенно возвращал ошибку на старый Failed статус
|
||||
- **Симптом**: terraform apply падает мгновенно без ожидания нового build
|
||||
- **Причина**: FunctionJob CRD хранил phase=Failed от предыдущего запуска
|
||||
- **Воркараунд**: удалить FunctionJob CRD перед apply
|
||||
|
||||
### Результат
|
||||
- vm-install-packages: status=ok, installed=[jq, python3-pip, htop, unzip]
|
||||
- vm-install-nginx: status=already_installed, version=1.18.0, http_check=200
|
||||
- vm-install-docker: status=ok, docker=29.3.1, compose=v5.1.1
|
||||
|
||||
### nubes провайдер
|
||||
Обновлён с 5.0.49 до 5.0.51 (fix: findInstanceUidByDisplayNameRefSvc возвращал deleted instance UUID)
|
||||
|
||||
Reference in New Issue
Block a user