# Runbook — OpenStack (Kolla-Ansible 2025.2, tout-en-un)

## Où sont les choses

| Élément | Emplacement |
|---|---|
| venv Kolla-Ansible + client `openstack` | `/opt/kolla-venv` (liens dans `/usr/local/bin`) |
| Configuration | `/etc/kolla/globals.yml` (copie de `kolla/globals.yml` du dépôt) |
| Inventaire | `/etc/kolla/all-in-one` (copie de `kolla/all-in-one`) |
| Mots de passe | `/etc/kolla/passwords.yml` — **serveur uniquement**, `600 root:root`, jamais dans Git |
| Accès admin | `/etc/kolla/clouds.yaml`, `/etc/kolla/admin-openrc.sh` (générés par `post-deploy`) |
| Collections Ansible de Kolla | `/root/.ansible/collections/` (installées par `install-deps`) |
| Journaux des déploiements | `/var/log/kolla-*.log` |

Tout ce qui précède (sauf les mots de passe et les fichiers générés) est
préparé par le playbook `ansible/kolla.yml` depuis le Mac :

```
cd ansible && script -q /dev/null ansible-playbook kolla.yml -i inventory.ini
```

## Choix de configuration (résumé de `kolla/globals.yml`)

- Images `debian` (tag `2025.2-debian-bookworm`).
- Toutes les API sur `dummy0` (10.10.0.1), jamais sur `eno1`. Pas de HAProxy ni keepalived (un seul nœud).
- Réseau externe Neutron : `veth-ext-ovs` (paire veth de l'étape 4), OVN.
- Heat, console série (`nova-serialproxy`), KVM, Prometheus, Grafana activés. Horizon désactivé.
- Cinder désactivé : pas de place pour un groupe de volumes LVM (disques entièrement en RAID 1).
- `disable_firewall: false` et Docker en `iptables: false`, `ip6tables: false`, `bridge: none`, `ip-forward: false` : **ni Kolla ni Docker ne touchent au pare-feu**, géré uniquement par le rôle `durcissement`.

## Déployer / redéployer

Sur le serveur, en root :

```
sudo -i
export PATH=/opt/kolla-venv/bin:$PATH
cd /etc/kolla
kolla-ansible bootstrap-servers -i all-in-one   # installe Docker, /etc/hosts…
kolla-ansible prechecks -i all-in-one
kolla-ansible deploy -i all-in-one              # 20 à 60 min la première fois
kolla-ansible post-deploy -i all-in-one         # génère clouds.yaml et admin-openrc.sh
```

Pour un `deploy` long, le lancer comme service pour survivre à une coupure SSH :

```
sudo systemd-run --unit=kolla-deploy \
  --setenv=PATH=/opt/kolla-venv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
  --setenv=HOME=/root --working-directory=/etc/kolla \
  bash -c 'kolla-ansible deploy -i /etc/kolla/all-in-one > /var/log/kolla-deploy.log 2>&1'
journalctl -fu kolla-deploy   # ou : tail -f /var/log/kolla-deploy.log
```

## Après chaque opération Kolla : vérifier le pare-feu

Kolla et Docker ne doivent créer aucune table nftables. Référence enregistrée
dans `/tmp/nft-reference.txt` (à refaire après un changement voulu) :

```
sudo nft list tables          # attendu : table inet filter, table ip nat
```

Si une table étrangère apparaît, comprendre d'où elle vient, puis recharger le
pare-feu depuis le Mac (sous filet anti-coupure) :

```
cd ansible && script -q /dev/null ansible-playbook reseau-openstack.yml -i inventory.ini \
  -e durcissement_forcer_rechargement=true
```

## Utiliser le client openstack

```
sudo -i
export OS_CLOUD=kolla-admin
export OS_CLIENT_CONFIG_FILE=/etc/kolla/clouds.yaml
openstack service list
openstack compute service list
openstack network agent list
```

## Pièges rencontrés

- `kolla-ansible install-deps` : `No such file or directory: 'ansible-galaxy'` si le `bin` du venv n'est pas dans le `PATH`.
- `prechecks` : `No module named 'docker'` — Kolla utilise le Python du venv, il faut `docker` et `dbus-python` **dans le venv** (fait par le rôle `kolla`).
- Docker 29 crée des tables `ip6 nat` / `ip6 filter` malgré `iptables: false` : ajouter `ip6tables: false` (`docker_custom_config` dans `globals.yml`).
- `kolla-genpwd` réécrit `passwords.yml` en `640` : le rôle remet `600`.

## Surcharges de configuration et projet des labs (étape 13)

- `kolla/config/nova/nova-compute.conf` (déposé par le rôle `kolla` dans `/etc/kolla/config/nova/`) :
  - `resume_guests_state_on_host_boot = true` : les VM redémarrent avec l'hôte (défaut Nova : elles restaient éteintes) ;
  - `reserved_host_memory_mb = 15000` : Nova refuse au-delà de 22 VM `eleve.petit` (voir `docs/capacite.md`).
  Après modification : `kolla-ansible reconfigure -i /etc/kolla/all-in-one --tags nova` (les VM en cours ne sont pas arrêtées). Le lancer comme service pour survivre à une coupure SSH :
  ```
  sudo systemd-run --unit=kolla-reconfigure-nova --setenv=PATH=/opt/kolla-venv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
    --setenv=HOME=/root --working-directory=/etc/kolla \
    bash -c 'kolla-ansible reconfigure -i /etc/kolla/all-in-one --tags nova > /var/log/kolla-reconfigure-nova.log 2>&1'
  ```
- Gabarit `eleve.petit` et quota du projet `paillasse` (40 instances, 40 vCPU, 30 Go) : rôle `openstack-projet` (`ansible-playbook openstack-projet.yml`).
- Vérifier ce que Placement accepte réellement : inventaire `MEMORY_MB` du fournisseur de ressources (`total`, `reserved`, `allocation_ratio`), par l'API Placement (le client `osc-placement` n'est pas installé).
- Services désactivés après un premier déploiement : leur unité systemd `kolla-<service>-container` est retirée par le rôle `kolla` (liste `kolla_services_retires`, aujourd'hui `proxysql`) et rangée dans `/root/unites-retirees/`.

## Redémarrage de l'hôte (testé le 2026-10-09)

Tout revient seul : les 46 conteneurs Kolla sont relancés par leurs unités systemd (et non par Docker, politique `no`), les VM par Nova, le reste par systemd. SSH en ≈ 3 min, services Kolla et VM ACTIVE en moins de 10 min.

Avant : sauvegarde récente et restauration testée, accord d'Adam, aucune modification réseau ou pare-feu en attente. Relevé comparable avant/après : `sudo /root/etat-serveur.sh` (services, unités Kolla, conteneurs, pare-feu, écoutes, réseau OpenStack, VM, socket du correcteur, Horizon, HTTPS, statut).

Juste après le démarrage, la table nftables `f2b-table` est absente : fail2ban ne la crée qu'à son premier bannissement (normal).