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>

docs/deploiement/image-qcow2.rst

@@ -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::
 

docs/developpement/lab.rst

@@ -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

scripts/lab-host.sh

@@ -337,7 +337,7 @@ push_file () {
 push_dir () {
     local SOURCE="${1}"
     COPYFILE_DISABLE=1 tar --no-xattrs -C "${SOURCE}" -cf - . \
-        | ssh_run -- "rm -rf topology.part && mkdir topology.part && tar -C topology.part -xf - && rm -rf topology && mv topology.part topology"
+        | ssh_run -- "rm -rf topology.part && mkdir topology.part && tar -C topology.part --no-same-owner -xf - && rm -rf topology && mv topology.part topology"
 }
 
 cmd_push () {

scripts/lab-host_test.sh

@@ -671,7 +671,7 @@ test_push_builds_for_linux_and_sends_binary_and_topology () {
     [[ $(cat "${WORK}/go.log") == "${REPO}|build -o ${WORK}/.cache/two-lab/lab ./cmd/lab|CGO_ENABLED=0 GOOS=linux GOARCH=amd64" ]] \
         || fail "compilation : $(cat "${WORK}/go.log")"
     grep -q "debian@203.0.113.7 cat > 'lab.part' && chmod 755 'lab.part' && mv 'lab.part' 'lab'" "${WORK}/ssh.log" || fail "envoi de lab absent"
-    grep -q "debian@203.0.113.7 rm -rf topology.part && mkdir topology.part && tar -C topology.part -xf - && rm -rf topology && mv topology.part topology" "${WORK}/ssh.log" \
+    grep -q "debian@203.0.113.7 rm -rf topology.part && mkdir topology.part && tar -C topology.part --no-same-owner -xf - && rm -rf topology && mv topology.part topology" "${WORK}/ssh.log" \
         || fail "envoi du répertoire absent"
     [[ $(cat "${WORK}/pushed.1") == "binaire-lab" ]] || fail "contenu de lab : $(cat "${WORK}/pushed.1")"
     LISTING=$(tar -tf "${WORK}/pushed.2" | sed 's|^\./||' | grep -v '/$' | grep -v '^$' | sort | tr '\n' ' ')