docs: fix configuration for errors

Signed-off-by: GnomeZworc <nicolas.boufidjeline@g3e.fr>

docs/deploiement/frr-hyperviseur.rst

@@ -1,43 +0,0 @@
-FRR sur les hyperviseurs
-========================
-
-FRR tourne sur chaque hyperviseur et peuple la table de transfert (FDB) des interfaces VXLAN
-créées par l'agent — c'est ce qui rend un subnet utilisable au-delà d'un seul nœud, puisque
-l'agent désactive l'apprentissage et ne configure aucun voisin.
-
-.. note::
-
-   **À rédiger.** À documenter :
-
-   * la version de FRR de référence et son mode d'installation, sachant que l'hyperviseur est
-     sans état : le paquet et la configuration doivent être posés à chaque démarrage, par le
-     bootstrap ou par un mécanisme équivalent ;
-   * les démons activés dans ``/etc/frr/daemons`` ;
-   * la configuration de référence : numéro d'AS, session vers le route reflector, famille
-     d'adresses utilisée pour annoncer les MAC et les VNI ;
-   * l'articulation avec les interfaces créées par l'agent : comment FRR découvre une interface
-     VXLAN qui apparaît à la création d'un subnet, et si une action est nécessaire ensuite ;
-   * ce qui se passe au démarrage à froid, quand FRR démarre avant ou après l'agent ;
-   * les commandes de vérification à utiliser en exploitation.
-
-Vérifier le plan de données
----------------------------
-
-Indépendamment de la configuration retenue, deux vérifications restent valables et méritent
-d'être dans toute procédure de diagnostic :
-
-.. code-block:: bash
-
-   # La FDB du VXLAN doit contenir des entrées vers les autres hyperviseurs.
-   # Vide, c'est le plan de contrôle qui ne fonctionne pas, pas l'agent.
-   ip netns exec <vpc> bridge fdb show dev <interface-vxlan>
-
-   # L'interface VXLAN telle que l'agent l'a créée : port 4789, learning off,
-   # aucun groupe multicast, aucun remote.
-   ip netns exec <vpc> ip -d link show <interface-vxlan>
-
-.. important::
-
-   Une FDB vide alors que le subnet est en ``running`` n'est **pas** un défaut de l'agent : il
-   crée délibérément l'interface sans apprentissage ni voisin, et laisse le peuplement au plan
-   de contrôle. Cf. :doc:`architecture-cluster`.

docs/deploiement/index.rst

@@ -2,25 +2,31 @@ Déploiement d'un cluster
 ========================
 
 Le :doc:`/demarrage/index` couvre un hyperviseur isolé : un VPC, un subnet, une VM, tout sur le
-même nœud. Cette section couvre ce qu'il faut mettre en place pour qu'un **parc** d'hyperviseurs
+même nœud. Cette section couvre la mise en place d'un **cluster** complet, dans l'ordre où les
-fonctionne ensemble — c'est-à-dire pour qu'un subnet s'étende à plusieurs nœuds.
+étapes se font.
 
-Ce n'est pas une extension du quickstart : le réseau du cluster doit exister **avant** que
+Cet ordre n'est pas indifférent : chaque étape a besoin de la précédente. L'image doit exister
-l'agent serve à quelque chose au-delà d'un nœud.
+avant qu'on puisse démarrer quoi que ce soit ; le réseau doit être en place avant le premier
+hyperviseur ; le route reflector est lui-même une VM, il lui faut donc un hyperviseur qui
+fonctionne.
 
-Ordre de mise en place
+Étapes
-----------------------
+------
 
-#. :doc:`architecture-cluster` — la topologie cible et ce que l'agent suppose déjà en place
+#. :doc:`architecture-cluster` — la topologie cible, à lire avant tout le reste
-#. :doc:`routeurs-cluster` — le routage entre hyperviseurs et vers l'extérieur
+#. :doc:`image-qcow2` — l'image golden dont dérivent toutes les VM du cluster
-#. :doc:`route-reflector` — la VM route reflector, point de rendez-vous du plan de contrôle
+#. :doc:`routeurs` — le matériel : routeurs de cluster, de datacentre et de bordure
-#. :doc:`frr-hyperviseur` — FRR sur chaque hyperviseur, qui peuple le plan de données
+#. :doc:`premier-hyperviseur` — le premier nœud, agent et plan de contrôle
+#. :doc:`route-reflector` — les VM route reflector
+
+D'autres étapes viendront à mesure que les composants d'orchestration seront livrés.
 
 .. toctree::
    :hidden:
    :maxdepth: 1
 
    architecture-cluster
-   routeurs-cluster
+   image-qcow2
+   routeurs
+   premier-hyperviseur
    route-reflector
-   frr-hyperviseur

docs/deploiement/route-reflector.rst

@@ -12,8 +12,9 @@ explicitement : la VM qui porte le plan de contrôle du cluster est hébergée p
 
    **À rédiger.** À documenter :
 
-   * la création de la VM : image de base, ressources, subnet et mode utilisés, s'il s'agit d'une
+   * la création de la VM : ressources, subnet et mode utilisés, et s'il s'agit d'une VM créée
-     VM créée par l'agent comme les autres ou d'un cas particulier ;
+     par l'agent comme les autres ou d'un cas particulier — l'image, elle, est l'image golden de
+     :doc:`image-qcow2` ;
    * son adressage, et comment les hyperviseurs le connaissent ;
    * la configuration du démon de routage qu'elle héberge ;
    * la redondance : une seule VM route reflector, ou deux, et sur quels hyperviseurs ;
@@ -21,7 +22,8 @@ explicitement : la VM qui porte le plan de contrôle du cluster est hébergée p
      absent — les tunnels déjà établis continuent-ils de fonctionner, et pendant combien de
      temps ;
    * la procédure d'amorçage : ce qui fonctionne, et dans quel ordre, quand on démarre un cluster
-     entier depuis zéro.
+     entier depuis zéro — le premier hyperviseur n'a pas de session FRR établie tant que cette VM
+     n'existe pas, cf. :doc:`premier-hyperviseur`.
 
 Points de vigilance
 -------------------

docs/deploiement/routeurs-cluster.rst

@@ -1,31 +0,0 @@
-Routeurs de cluster
-===================
-
-Les routeurs de cluster raccordent les hyperviseurs entre eux et au monde extérieur. Ils
-préexistent à l'agent : celui-ci ne les configure pas et n'en a aucune connaissance.
-
-.. note::
-
-   **À rédiger.** Cette page attend les éléments de terrain. À documenter :
-
-   * le rôle exact des routeurs dans la topologie : passerelle du réseau d'hyperviseurs,
-     terminaison du routage externe, ou les deux ;
-   * le matériel ou le logiciel employé, et la version de référence ;
-   * la configuration de référence : interfaces, adressage, protocole de routage employé avec
-     les hyperviseurs, numéros d'AS si BGP ;
-   * la redondance : combien de routeurs, quel mécanisme de bascule, quel comportement attendu
-     pendant une bascule ;
-   * le MTU configuré sur les liens vers les hyperviseurs — il doit tenir compte des 50 octets
-     d'encapsulation VXLAN, cf. :doc:`architecture-cluster` ;
-   * le filtrage : ce qui est autorisé entre hyperviseurs (au minimum UDP 4789), et ce qui est
-     autorisé depuis l'extérieur.
-
-Points de vigilance
--------------------
-
-.. warning::
-
-   L'API de l'agent n'a **aucune authentification**. Le filtrage réalisé par les routeurs de
-   cluster est aujourd'hui l'une des rares barrières entre cette API et le reste du réseau : le
-   port de l'API ne doit être joignable que depuis le réseau d'administration.
-   Cf. :doc:`/exploitation/configuration`.

docs/index.rst

@@ -55,11 +55,7 @@ Par où commencer
    :hidden:
    :caption: Exploitation
 
-   exploitation/configuration
+   exploitation/index
-   exploitation/services
-   exploitation/api-agent/index
-   exploitation/observabilite
-   exploitation/diagnostic
 
 .. toctree::
    :hidden: