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:
parent
bc05fd9c89
commit
f9aadc00fc
4 changed files with 56 additions and 8 deletions
|
|
@ -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::
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue