Préparation au 08/03/2026 : passage à la V2

Support Duniter-v2
82

Est-ce que l’on sait si le g1_metadata.scale devrait rester stable d’ici la release (histoire de mettre à jour pour g1cli ) ?

83

A priori oui.

1 Like
84

Question subsidiaire, c’est quoi la meilleure manière de le récupérer ?

85

comme ça c’est le mieux, ou via mon noeud rpc.

1 Like
86

Je veux bien, mais je manque de temps avec le boulot. Je vais essayer de checker des trucs tard ce soir ou demain soir.

Par contre, pourquoi as-tu versionné le runtime G1 avec spec_version à 1200 ? C’était censé être 1100 comme le GTest. Maintenant, je dois renommer toutes les milestones GitLab runtime-1200 et supérieures.

Il faut vraiment qu’on prenne l’habitude de release les runtimes GTest et G1 sous le même numéro de spec_version, quitte à les release en même temps sur la même release page.

87

J’allais vous poser la question à ce sujet, pas de soucis ce sera 1100 le jour J, cet essai est à blanc et il n’en restera aucune trace. Je me suis posé la question justement.
Et j’ai créer une MR pour changer la convention de nommage des tag et jalon runtime comme on en a discuté.

Du coup est-ce que tu veux que je maintienne ce fake réseau g1 jusqu’a demain pour pouvoir tester ou je le supprime avant ?

1 Like
88

Si ce n’est pas trop contraignant pour toi de le maintenir quelques jours, ça peut être utile. Si tu as changé des choses dans le process et que tu préfères le supprimer et le relancer, ça me va aussi. J’aimerais simplement pouvoir prendre un peu de temps, avant la migration, pour vérifier quelques éléments sur une G1 live d’essai.

2 Likes
89

Pas de soucis pour le maintenir, pas impossible que j’en fasse un reboot, ou pas, mais je peux maintenir ça sans soucis.

Aussi le jour J je ferais un bump de la version du client à 1.0.0 au lieu de 0.13.0 si ça vous va.
On aura donc un tag client g1-1100-1.0.0.

4 Likes
90

Pas de souci tant que tu reboot sur les même endpoint

Ce serait même mieux de faire un bump du client en version 2.0.0 afin de pouvoir réutiliser le même paquet Debian que pour Duniter v1. Je crois que @Moul avait demandé cela.

2 Likes
91

Ah c’est comme vous voulez, vous me dites, ping @Moul @cgeek @HugoTrentesaux

2 Likes
92

Il y a aussi ce ticket qui mentionne que nous devons renommer le binaire « duniter2 » en « duniter » :
"Package/Binary name (#238) · Issues · nodes / rust / Duniter v2S · GitLab

1 Like
93

Oui, ce serait chouette que ça s’appelle toujours Duniter, juste en version 2 !

5 Likes
94

@elois Le bug de gui_tooun sur la migration (unknown15.UnknownError, sera mieux décodé prochain build de gecko), j’ai creusé un peu.

Il n’a jamais été online sur v2, donc last_online = None. Je crois que dans KeyChangeHandler::on_changed (runtime/common/src/handlers.rs), le bond check passe (None + pas dans le set online()), puis ça arrive à authority_members::change_owner_key() qui tente de migrer les session keys pré-remplies au genesis depuis la v1. Le set_keys(new_key, proof: vec![]) plante côté pallet session, sûrement NoAccount ou InvalidProof.

Faudrait peut-être juste purger les keys sans les réassocier quand le smith est offline, non ?
je ne suis pas très sûr de moi sur ce coup, mais je met ça là.

95

Les réassocier n’est effectivement pas obligatoire quand le smith est offline, mais le faire quand même n’est pas censé poser problème et ne résoudrait pas la cause de ton bug de toute façon, voir mon autre message ici: Ğecko talks / user support - #674 by elois

96

Reboot G1 de test

Je viens de relancer le réseau g1 de test, @smiths-v2 vous pouvez lancer des noeuds mirroir, squid, migrer vos comptes, puis lancer des noeud smiths pour tester :slight_smile:

Par contre je ne vais pas set le hash genesis pour les clients donc Gecko ne pourra pas se connecter à ce réseau.

Noeud boostrap

:right_arrow: Mirroir: wss://g1.p2p.legal/ws
:right_arrow: Squid: https://g1-squid.axiom-team.fr/graphiql

:warning: Changement de nom des images Docker

Comment ce n’était pas assez drôle de prévoir ce genre de chose à l’avance, ont a décidé de changer le nom des images docker la veille du lancement.

L’image docker s’appelle désormais duniter, et non plus duniter-v2s.
Le tag de version du client est 2.0.0.

L’image a utiliser le jour J (et actuellement pour cette g1 de test) est donc:

:right_arrow: duniter/duniter-g1-1100:1100-2.0.0

Encadrez le, c’est la version définitive à utiliser le jour J :slight_smile:

@elois est-ce que tu valides que tout est conforme pour toi, en terme de nomage, versions, images ?

8 Likes
97

Attention, l’image Docker a déjà été publiée. On peut republier demain sous le même nom et le même tag, mais tous ceux qui l’auraient déjà pull aujourd’hui doivent bien penser à supprimer l’image sur leur serveur pour forcer le re-pull, sinon c’est l’ancienne image locale qui sera utilisée.

Pour éviter tout problème demain, je te recommande de publier le binary sous la version 2.0.1 ou supérieure, bref d’incrémenter le patch semver à chaque reboot.

Les versions sont bien 1100 pour le runtime et 2.0.0 pour le binary/client. Par contre, je ne comprends pas pourquoi on met la version du runtime dans le nom de l’image : ça ne sert strictement à rien. On devrait nommer les images duniter-gtest et duniter-g1 et ne placer les versions de runtime que dans le tag.

Si on reboot un réseau avec un nouveau genesis, on est censé upgrader la version du binary, car le binary contient les genesis chain spec, donc ce n’est pas le même.

1 Like
98

Cooncernant le nom des images docker, je t’invite à voir ma position depuis un certain temps: Duniter v2s Docker images and tags names

Mais c’est un choix qui n’est pas le miens, tout le monde semble en accords avec la situation actuelle, donc si ça convient à tout le monde, on laisse jusqu’a nouvel ordre.

Et honnêtement là je ne vais pas changer les tag ce soir avant le lancement, mais comme je le précise dans mon message où tu peux y répondre, je suis pour changer ça effectivement.

Concernant le tag 2.0.0, alors je m’apprêtait à demander à tous les forgerons de couper leur noeud duniter avant le vrai lancement, de faire un docker system prune -a, puis docker compose pull, ainsi aucun problème possible.

Je voulais vraiment tester ISO prod jour J donc avec le même tag.
Mais on peut incrémenter la version du client en 2.0.1 si vous préférez, de toute facçon il n’y aura plus aucune trace de ce 2.0.0 d’ici demain matin.

2 Likes
99

Noeud forgeron en attente de passer online :slight_smile:

g1cli --no-indexer smith show-online
Online:
61
Incoming:
12242
Outgoing:

Je regarde pour démarrer Archive & Squid :slight_smile:

3 Likes
100

Archive up et Squid en initialisation.

Du coup, pour l’image à utiliser pour Duniter v2; le mieux est sans doute d’utiliser le latest ?

duniter/duniter-g1-1100:latest

Ou bien il pourrait y avoir un risque ?

101

SI tu utilise latest il faudra bien faire docker compose pull avant de lancer.
Pour être sûr tu peux même faire docker system prune -a avant, en ayant bien coupé ton noeud duniter avant.

Sinon il risque de garder le cache stale de l’image latest que tu as déjà en local.

1 Like