Chronologie de la migration

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
14 Likes

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.

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

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

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

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

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

2 Likes

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

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

Je suis en train de rédiger la com sur cette bascule.
La Ğ1 version 2 - CodiMD

J’aimerais des précisions.
On avait parlé d’une dernière version de Cesium1 prévue pour éviter toute action sur la blockchain après la prise d’image. Cette idée sera-t-elle mise en œuvre ?

Il avait également été question d’une dernière version de Duniter1 dans le même but. Est-ce toujours dans les tuyaux ?

J’attends aussi toutes vos remarques sur le scénario pour l’utilisateur que j’ai écrit.

1 Like

La MR de @poka est prête, mais il n’a pas les mains sur les store d’application, il faut donc une action de @kimamila si on veut release sur le play store et l’app store il me semble.

J’avais pensé à un simple script qui kill Duniter1 et le restart avec une clé non membre, ce qui arrêterait la production de blocs. Ce serait plus simple que déployer une nouvelle version de Duniter. Ce script n’est pas écrit mais c’est l’affaire de moins d’une heure et je suis sûr qu’on trouvera un volontaire pour s’en charger :joy:

Ce serait donc à chaque forgeron de le lancer au moment de la prise d’image ou un peu avant ?

Et il est OK pour le faire ?

Le script pourrait contenir une date d’action programmée, et on lancerait le snapshot à peu près au même moment. De sorte qu’il suffirait de lancer le script entre le choix de la date (et publication du script) et le jour J.

Ce serait bien d’avoir quelques nouvelles de @kimamila. D’autre part, il n’y a eu aucune avancée apparente sur Cesium v2. J’ai pas trop le temps de coordonner tout ça en ce moment :confused:

J’interviens pour poser une question : le développeur employé de @kimamila pour Cesium2 est embauché suite au CF 2024 ?
Cette réponse nous permet, en tant que Collectif MàJ-V2, d’avoir des réponses aux questions des utilisateurs.
Puis-je faire quelques chose pour aider à faire avancer ?

3 posts were split to a new topic: Demande de relecture plan de communication

pas “embauché”, il est déjà salarié. Les 6k lui permettent de l’affecter à cesium2, le mobiliser, le “dédier”.
Je lui ai demandé un doc de type “lettre de mission”, ainsi qu’à Axiom pour Benjamin, afin de partager ça avec les donateurs et la comm v2.

2 Likes

Après une longue absence (plus de 2 ans) pour raisons personnelles, je suis impressionné de voir tout ce que vous avez accomplis depuis 2 ans, toutes mes félicitations.

J’envisage de revenir en tant qu’observateur, et peut-être faire de la communication/vulgarisation auprès des utilisateurs pour faire le ponts ente les dev et les utilisateurs. Mais je ne compte pas m’impliquer de nouveau techniquement dans le code ni dans le maintien d’un noeud, et ne souhaite pas faire parti du futur comité technique.

Je viens de discuter au téléphone avec @HugoTrentesaux concernant la chronologie de la migration et j’ai une suggestion:

Lancer une Ğ1v2 temporaire (quelques mois) identique techniquement à ce que sera la vraie Ğ1v2 mais avec un comité technique réduit pour pouvoir la détruire facilement. Et maintenir la Ğ1v1 en parallèle pendant une durée suffisante pour tester quasiment toutes les fonctionnalités (quelques mois?).

L’objectif serait de réaliser un test grand public en conditions réelles. Et si tout ce passe bien faire la vraie migration avec exactement le même runtime mais juste la snapshot de départ qui change.

Détruire directement la Ğ1v1 me semble risqué, certain bug ne sont découvert qu’en conditions réelles. Le simple changement de nom de runtime ou de prefix ss58 peut causer des bug non anticipés dans certains tools ou UI.

Aussi, étant donné que tout repose principalement sur des bénévoles, j’ai l’impression que cela demanderai trop d’effort de maintenir trois réseaux différents en même temps. Peut-être serait-il préférable de ne maintenir que deux réseaux : ĞDev et Ğ1.

Pour tester les futures mises à jour il est possible de déployer un fork/clone de la Ğ1 avec le même runtime mais des chain-spec différentes, c’est ce qu’on fait chez Moonbeam (une blockchain en production basée sur substrate, je travaille full-time pour eux depuis 4 ans).

Voila, ça fait bizarre de revenir sur ce forum après ci longtemps mais ça fait plaisir :slightly_smiling_face:

Je viendrais peut-être à certaines visio en tant que observateur / conseiller extérieur.

12 Likes

En effet ça va être difficile de trouver des forgerons pour toutes les chaînes (personnellement je n’ai qu’un RPi4 donc me limiterai à forger la gdev).

Pour cette chaîne g1 temporaire, comment éviter que les gens soient perdus ? (que ce soit clair que c’est une monnaie de test, parallèle à la vraie)

  • La nommer autrement que Ğ1. (ĞTest…) (même si le runtime garde le nom technique g1) Mais ça ajoute une différence qui risque de faire planter des clients. De plus certains clients pourraient avoir hardcodé le nom.
  • Gérer ça côté client. (vérification de date ou autre qui affiche un avertissement) Ça rend la transition immédiate (la même appli continuera à fonctionner lors de la vraie migration) mais ça demande pas mal de coordination et de travail.

L’idéal serait de la nommer Ğ1.
En terme d’UX, l’idéal serait d’avoir un message dans un cadre orange dès qu’on essaye de réaliser une transaction (ou constamment) du genre “attention: Monnaie de Test. Toutes les transactions et certifications que vous réalisés ici seront supprimées lors de la prochaine réinitialisation: en savoir plus”

Avec le “en savoir plus” qui pointe vers un post ou une page qui explique bien le processus de test grandeur nature, et qui mentionne qu’il faut toujours passer par la Ğ1v1 pour les opérations que l’on souhaite persister définitivement.

2 Likes

Salut Eloïs, content de te revoir par ici :slight_smile:

Même si tu ne participes pas beaucoup, je crois que ton aide nous sera très bénéfique. Tu avais déjà beaucoup d’avance sur nous il y a 2 ans, aujourd’hui tu pourras sûrement nous éviter bon nombre d’erreurs.

Concernant ta proposition de passer direct à un réseau Ğ1 jetable, l’idée me va bien du moment que l’on a les gardes-fous pour la rendre jetable. A priori c’est le cas car on a la main sur le taux de création monétaire c via le fichier de paramétrage des chain-specs (ud_creation_period), ça me semble déjà suffisant.

Et +1 il faut absolument avoir ce message de prévention qu’il s’agit d’un tir à blanc partout.

4 Likes