fix(vm_stress_test): make read-only workflow, add instructions and docs

2026-03-30 07:16:35 +03:00
parent fef441681e
commit 56e6446310
4 changed files with 1104 additions and 58 deletions
@@ -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 — Оценка трудозатрат на проект

 | Компонент | Оценка |