init

2026-02-19 11:34:13 +00:00
commit f243f440c3
191 changed files with 6183 additions and 0 deletions
--- a/documentation/issues/issue-0.md
+++ b/documentation/issues/issue-0.md
@@ -0,0 +1,88 @@
+# Bug Report: cloud-init расширение root-диска ломается из-за «рандомного» имени диска (/dev/sda не всегда root)
+
+## TL;DR
+Скрипт в `terraform cloud-init` жёстко использует `/dev/sda`, но система **не всегда** назначает root-диск как `sda`. Иногда root оказывается на `sdc` (или другом), из‑за чего `runcmd` частично/полностью не выполняет расширение LVM и файловой системы.
+
+---
+
+## Контекст
+В `cloud-init` используется `runcmd`, который расширяет разделы и LVM на диске `/dev/sda`:
+
+```yaml
+runcmd:
+  - |
+    set -euxo pipefail
+
+    # растянуть extended + LVM partition до конца диска
+    growpart /dev/sda 2 || true
+    growpart /dev/sda 5 || true
+    parted -s /dev/sda "resizepart 2 100%" "resizepart 5 100%" || true
+    partprobe /dev/sda || true
+
+    # растянуть PV -> LV(root) -> FS
+    pvresize /dev/sda5
+    lvextend -l +100%FREE -r /dev/vg0/root
+```
+
+---
+
+## Симптомы
+- После первого бута root‑раздел **не расширен** (LVM/FS остаются маленькими).
+- В `cloud-init status --long` возможны ошибки в `scripts-user / runcmd` (если команды без `|| true` падают).
+- Скрипт «работает в большинстве случаев», но **иногда ломается** без изменений в конфиге.
+
+---
+
+## Наблюдение (доказательство)
+Одинаковая VM‑логика, но root‑диск получает разные имена.
+
+### Случай A (работает): root на `sda`
+```
+sda  30G  disk
+├─sda1  /boot
+└─sda5
+  └─vg0-root  /
+sdb 150G disk
+sdc 150G disk
+```
+
+### Случай B (ломается): root на `sdc`
+```
+sda 150G disk
+sdb 150G disk
+sdc  30G  disk
+├─sdc1 /boot
+└─sdc5
+  └─vg0-root  /
+```
+
+---
+
+## Причина (root cause)
+Имена `/dev/sdX` **не гарантированы**: порядок обнаружения дисков может меняться (особенно в VM/Proxmox при разных контроллерах/порядке подключения).  
+Скрипт предполагает, что root всегда на `/dev/sda`, но когда root на `/dev/sdc`, команды `growpart/pvresize` применяются к **не тому** диску.
+
+---
+
+## Ожидаемое поведение
+Скрипт должен определять **реальный диск**, на котором смонтирован `/`, и работать с ним (а не с фиксированным `/dev/sda`).
+
+---
+
+## Фактическое поведение
+Скрипт работает только когда root-диск случайно оказывается `sda`. При других раскладах расширение не происходит.
+
+---
+
+## Влияние
+- Интермиттентный (рандомный) фейл на bootstrap VM.
+- На части VM root остаётся маленьким → проблемы при установке пакетов/логах/кэше и т.д.
+- Сложно диагностировать, т.к. «иногда всё ок».
+
+---
+
+## Почему сейчас не фикшу
+Баг проявляется редко и не хочу тратить время на стабильное авто‑определение диска прямо сейчас.  
+В большинстве случаев root всё же назначается на `sda`.
+
+---
--- a/documentation/issues/issue-1.md
+++ b/documentation/issues/issue-1.md
@@ -0,0 +1,85 @@
+## Заголовок
+**[cephadm/bootstrap] Bootstrap падает на `orch host add`, если SSH на ноде не на 22 (custom port 10225)**
+
+## TL;DR
+`cephadm bootstrap` во время установки пытается добавить bootstrap-хост в orchestrator через SSH на **порт 22**. Если SSH слушает **10225**, bootstrap ломается с ошибкой `Can't communicate with remote host ... Connect call failed (ip, 22)`.
+
+## Контекст
+- Компонент: **Cephadm / ceph orch (orchestrator backend: cephadm)**
+- ОС: Debian 13 (trixie), VM (Proxmox)
+- SSH: **sshd слушает 10225**, порт 22 закрыт/не слушает
+- Ceph: `cephadm 18.2.7` (reef), `ceph-common 18.2.7`
+- Сеть: `192.168.0.0/24`, bootstrap mon-ip: `192.168.0.102`
+
+## Шаги воспроизведения
+1. На ноде включить SSH только на кастомном порту:
+   - `Port 10225`
+   - порт 22 не слушает/закрыт
+2. Запустить bootstrap:
+   ```bash
+   cephadm bootstrap \
+     --mon-ip 192.168.0.102 \
+     --initial-dashboard-user admin \
+     --initial-dashboard-password password \
+     --allow-fqdn-hostname
+   ```
+3. Дождаться шага добавления хоста в orchestrator.
+
+## Ожидаемое
+- Bootstrap завершён успешно.
+- Bootstrap-нода добавлена в `ceph orch host ls`.
+- `ceph -s` и `ceph orch ps` работают.
+
+## Фактическое
+- Bootstrap прерывается на добавлении bootstrap-хоста в orchestrator:
+  - `Error EINVAL: Can't communicate with remote host ...`
+  - `Connect call failed ('192.168.0.102', 22)`
+- Кластер остаётся в “полуразвернутом” состоянии и требует cleanup через `cephadm rm-cluster`.
+
+## Логи / доказательства
+Команда:
+```bash
+cephadm bootstrap \
+  --mon-ip 192.168.0.102 \
+  --initial-dashboard-user admin \
+  --initial-dashboard-password password \
+  --allow-fqdn-hostname
+```
+
+Фрагмент вывода:
+```text
+Generating ssh key...
+Wrote public SSH key to /etc/ceph/ceph.pub
+Adding key to root@localhost authorized_keys...
+Adding host dev-kyiv01-vm-ceph-main-01...
+...
+Error EINVAL: Can't communicate with remote host `192.168.0.102`
+[Errno 111] Connect call failed ('192.168.0.102', 22)
+```
+
+Проверки, подтверждающие причину:
+```bash
+ss -lntp | grep sshd              # показывает слушает 10225, нет :22
+nc -vz 192.168.0.102 22           # refused/failed
+nc -vz 192.168.0.102 10225        # ok
+```
+
+## Root cause (гипотеза/факт)
+- Факт: `cephadm bootstrap` внутри запускает `ceph orch host add <hostname> <mon-ip>` для bootstrap-ноды и пытается достучаться до неё по SSH на **22/tcp**.
+- При SSH на 10225 соединение на 22 не устанавливается → bootstrap падает.
+
+## Влияние
+- Частота: **always**, если sshd не слушает 22.
+- Impact:
+  - невозможно быстро поднять кластер “из коробки” при custom ssh port
+  - остаются артефакты “битого” кластера (нужен ручной purge)
+
+## Workaround
+1. Временно открыть/включить SSH на 22 в mgmt-сети
+
+## План фикса / идеи
+- Попробовать bootstrap/оркестратор с явной настройкой SSH порта через ssh_config для cephadm (custom port 10225):
+  - подготовить отдельный ключ и `ssh_config` с `Port 10225`
+  - прокинуть его в bootstrap (например через параметры вида `--ssh-config`, `--ssh-private-key/--ssh-public-key`, `--ssh-user` — зависит от версии/пакета)
+  - после поднятия закрепить ssh_config для cephadm module (чтобы `ceph orch host add` всегда использовал 10225)
+- Если “быстро и надёжно” не выходит — принять стандарт: **внутри mgmt/VPN оставить 22**, с firewall allowlist (а наружу не публиковать вообще), а 10225 использовать только там, где реально нужно.
--- a/documentation/issues/template.md
+++ b/documentation/issues/template.md
@@ -0,0 +1,39 @@
+# Мини‑шаблон для будущих баг‑репортов (копипаст)
+## Заголовок
+**[Компонент] Короткое описание проблемы (симптом + причина/условие)**
+
+## TL;DR
+1–2 предложения: что ломается и почему важно.
+
+## Контекст
+- где (сервис/скрипт/модуль)
+- версия/окружение (OS/VM/провайдер/конфиг)
+
+## Шаги воспроизведения
+1.
+2.
+3.
+
+## Ожидаемое
+-
+
+## Фактическое
+-
+
+## Логи / доказательства
+- команды
+- вывод
+- скрин/фрагменты конфигов
+
+## Root cause (гипотеза/факт)
+-
+
+## Влияние
+- частота (always/sometimes)
+- риск/impact
+
+## Workaround
+-
+
+## План фикса / идеи
+-