Chronologie de la migration

Networks
1

Je lance ce post pour lister un maximum de détails sur le déroulé précis de la migration dans un scénario idéal (les échecs possibles et solutions de repli seront dans un autre post). Il sera complété et ajusté au fur et à mesure. J’imagine le “0” au 8 mars 2025, mais on peut ajuster en fonction de notre état de préparation et des disponibilités des personnes cruciales bien entendu.

  • J-40 La toile forgeron initiale est constituée à partir des personnes suffisamment entraînées sur les ĞDev.
  • J-30 Lancement “à blanc” d’un réseau ĞTest similaire au réseau Ğ1 (cf détails ci-dessous). Ce lancement permettra d’identifier les éventuels points de friction et de préciser les timings.
  • J-15 L’installation de Cesium v2 et son test depuis plusieurs plateformes sur le réseau ĞTest est concluant, aucun gros problème d’utilisabilité n’est soulevé.
  • J-7 Les données hors chaînes sont importées dans les datapods avec le préfixe SS58 de la Ğ1.
  • J-5 Le fichier de conf du réseau est figé (toile forgeron initiale, comité technique, paramètres, préfixe ss58…).
  • J-4 Les endpoints p2p de deux-trois nœuds de bootstrap sont connus d’avance (dns et peerid, implique d’injecter node.key avant le démarrage du nœud).
  • J-1 Un dernier coup de communication est lancé sur un maximum de plateformes pour encourager à arrêter d’utiliser la Ğ1 en attendant qu’elle soit déplacée sur la v2.
  • H-1 Le processus de migration est lancé :
    • Le backup de la db duniter v1 du noeud de cgeek est lancée (tar -cvzf).
    • La CI py-g1-migrator est lancée.
    • La CI publie automatiquement une page de release avec les assets genesis (comme runtime-800) et ses logs.
  • :star:=0 Le premier nœud validateur v2 est lancé par cgeek Hugo en utilisant les raw chainspecs g1 produites ci-dessus.
    • Le champ “migration” du fichier g1.json est mis à true, et le hash du genesis est ajouté. Cela affiche une popup bloquante aux personnes ayant installé “Cesium 1.99” (cf Mise à jour forcée de Cesium (en douceur)).
    • Un post sur le forum est publié dans la foulée pour annoncer le nouveau réseau (similaire à ĞDev Runtime 800 -- new network - #13 by cgeek).
    • Les nœuds miroir rejoignent le plus rapidement possible pour exposer leur endpoint RPC.
    • Les live tests sont lancés sur le storage pour vérifier qu’il n’y a pas d’incohérence au démarrage.
    • Les nœuds archive+squid rejoignent le plus rapidement possible pour exposer leur endpoint graphql.
    • Le champ “active” du fichier g1.json est mis à true, indiquant que la mise-à-jour est confirmée et que le réseau est ok pour être utilisé.
  • M+10 En dix minutes (environ 100 blocs v2), un client est entièrement fonctionnel (capable de se connecter à un endpoint rpc synchronisé et un endpoint squid synchronisé).
  • H+1 Les premiers forgerons ayant fait leur “go-online” après le lancement entrent dans les autorités.
  • H+2 Les nouvelles autorités commencent à calculer des blocs.
  • J+1 La nuit est passée, rien ne s’est écroulé, les blocs sont forgés à intervalles réguliers.
  • J+2 Les données hors chaînes manquantes sont à nouveau importées dans les datapods.
  • J+5 Aucun incident n’est déclaré, la Ğ1 continue sur la v2 comme sur des roulettes. Il est maintenant temps de répondre à la vague de questions qui ne manquera pas d’arriver :sweat_smile:. Et on peut lancer un autre coup de comm pour dire que c’est ok. Il reste quelques actions :
    • mettre à jour la documentation et les sites officiels pour déprécier la doc v1 et mettre en avant la doc v2
12 Likes
2

Je viens de voir que le 8 mars 2025 tombe un samedi.
Il serait peut-être judicieux de décaler légèrement pour ne pas faire la bascule le week-end, c’est le moment où il y a le plus d’activité, je crois.

3

Tchois avait déjà dit ça dans le sujet “Une date pour la migration?”. Mais d’un autre point de vue, ça garantit que le maximum d’informaticiens puissent bloquer leur journée pour être sur le pont si nécessaire. Perso je pense que la migration est une étape assez importante pour qu’on mette les chances de notre côté plutôt que cacher ça sous le tapis. Mais on verra quand on y sera, là c’est la chronologie relative qui est importante, pas la date absolue.

3 Likes
4

Bravo, Hugo. C’est incroyable ce que tu as fait.

5

S’il y a bien quelqu’un à qui devrait revenir cette tâche symbolique c’est à toi, Hugo.

Je veux bien faire partie du comité technique, en revanche.

5 Likes
6

Ok, je peux faire ça. Est-ce que tu as utilisé une version pré-compilée de Duniter en lui donnant les chainspecs en argument ? Est-ce que c’était dans docker ? Je suis toujours pas hyper confiant dans mes compétences d’adminsys, j’espère que je ferai pas de bourde :see_no_evil:

2 Likes
7

j’en connais qui vont pas bien dormir cette nuit là pour être sûr que rien ne s’écroule :wink:

2 Likes
8

Je ne me rappelle plus très bien, mais je crois que j’ai procédé manuellement : j’ai démarré à partir du code source une gdev_live. Puis quand tu m’as rejoint j’ai débrayé le nœud pour passer sur la version dockerisée.

1 Like
9

Je viens de voir que YunoHost a sortie la v12 hier, la veille d’un jour férié et d’un week-end.
Ça m’a fait penser que ça serait une bonne idée de déclencher la migration avant les jours fériés.
Ça permet aux développeurs, forgerons et contributeurs de se dégager plus de temps pour réagir en cas de pépins, s’occuper d’accueillir cette évolution, de s’installer confortablement dans notre nouvelle demeure.

Si on va dans cette direction, il y a plusieurs jours en avril, mai et juin.
C’est un peu plus tard que le 8 mars, mais ça peut également être une option en cas de retard dans le planning.

3 Likes