fix(vm_stress_test): make read-only workflow, add instructions and docs
This commit is contained in:
Naeel
+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