f-50: lab: seedfrom avec barre oblique finale, push sans propriétaire, résultats d'E4 #50

Signed-off-by: GnomeZworc <nicolas.boufidjeline@g3e.fr>
This commit is contained in:
GnomeZworc 2026-10-04 19:37:57 +02:00
commit f9aadc00fc
Signed by: nicolas.boufideline
GPG key ID: 4406BBBF8845D632
4 changed files with 56 additions and 8 deletions

View file

@ -250,7 +250,7 @@ champ ``password`` de l'API de l'agent ne sert donc **pas** à ouvrir une sessio
datasource_list: [ NoCloud ]
datasource:
NoCloud:
seedfrom: 'http://169.254.169.254:80'
seedfrom: 'http://169.254.169.254:80/'
timeout: 5
max_wait: 10
ENDFILE
@ -315,12 +315,20 @@ Points de vigilance
aucun espace à l'host : les qcow2 ne se rétractent pas. L'activation reste utile pour le jour
où l'option sera ajoutée côté agent, mais ne pas compter dessus pour la place disque.
.. note::
.. warning::
**À vérifier** — ``seedfrom`` sans barre oblique finale. cloud-init construit l'URL des
documents en concaténant ``seedfrom`` avec ``meta-data`` et ``user-data``. Confirmer sur une
VM réelle que les deux documents sont bien récupérés, et corriger en
``http://169.254.169.254:80/`` si ce n'est pas le cas.
**La barre oblique finale de** ``seedfrom`` **est indispensable avant cloud-init 23.1.**
cloud-init construit l'URL des documents en concaténant ``seedfrom`` avec ``meta-data``,
``user-data`` et ``vendor-data`` (``util.read_seeded``). Jusqu'à la 22.4 — celle de Debian 12,
22.4.2 —, sans barre oblique finale il demande ``http://169.254.169.254:80meta-data`` : la
source échoue, la VM démarre en ``DataSourceNone``, sans nom d'hôte ni user-data. À partir de
23.1, un drapeau actif par défaut (``NOCLOUD_SEED_URL_APPEND_FORWARD_SLASH``) ajoute la barre
oblique manquante, ce qui explique qu'une image récente fonctionne sans elle.
Vérifié le 2026-10-04 dans le lab (#50), sur une VM Debian 12 lancée par l'agent : sans barre
oblique, ``Datasource DataSourceNone`` ; avec, ``DataSourceNoCloudNet
[seed=…http://169.254.169.254…]`` et le nom d'hôte de la VM. Avec la barre oblique, la
configuration fonctionne quelle que soit la version de cloud-init.
.. note::

View file

@ -372,6 +372,46 @@ secours, et la VM redémarrée ne rejoue pas ``runcmd``.
exécuté qu'au premier, et la migration réseau, qui n'est pas persistée, est perdue. Recréer le
lab : ``lab down`` puis ``lab up``.
Vérifié le 2026-10-04 sur le serveur de lab, topologie ``evpn-2hv``, release ``0.2.0rc002`` :
.. code-block:: text
$ scripts/lab-host.sh ssh './lab up -timeout 25m topology/evpn-2hv.yml'
sw1: started
rr1: started
hv1: started
hv2: started
sw1: ready
rr1: ready
hv1: ready
hv2: ready
.. list-table::
:header-rows: 1
:widths: 55 45
* - Vérification
- Résultat
* - ``lab up`` complet : FRR, ``deploy.sh`` et vérification des services de chaque rôle
- 6 min 15
* - session switch ↔ route reflector, IPv4 unicast, BFD
- Established, BFD up ; le switch reçoit la seule loopback du route reflector
* - sessions EVPN des deux hyperviseurs vers la loopback du route reflector
- Established, voisins dynamiques, stables
* - réseau d'un hyperviseur après ``deploy.sh``
- adresse sur ``br-000000``, MTU 9000, API de l'agent qui répond
* - VPC, subnet ``vxlan`` et VM Debian ``genericcloud`` créés par l'API de hv1
- ``login:`` en 20 s, en KVM imbriqué
* - DHCP et routes (option 121) servis par two à la VM
- conformes, route ``/32`` vers ``169.254.169.254`` comprise
* - métadonnées, image configurée selon :doc:`/deploiement/image-qcow2`
- ``DataSourceNoCloudNet``, nom d'hôte appliqué — avec la barre oblique finale de
``seedfrom`` (voir cette page)
* - VM ↔ VM entre les deux hyperviseurs, même subnet ``vxlan``
- **échec** : les VXLAN de two n'ont pas d'adresse VTEP locale, rien n'est annoncé en EVPN —
`#51 <https://git.g3e.fr/syonad/two/issues/51>`_ ; avec l'adresse posée, ping et MTU 1500
passent
.. note::
La configuration du switch (``conf/lab/frr/sw1.conf``) **n'est pas celle des routeurs** : écrite