A priori pour le démarrage je me propose de me lancer en solo parmi les autorités online, donc seulement mes sessions_keys de renseignées dans le fichier gdev.json puis vous me rejoignez au fur et à mesure.
Il faut aussi décider de la sudo_key, pour l’instant j’ai laissé celle par défaut.
Il me semble que first_ud et first_ud_reeval sont des timestamps. Dans ce cas les valeurs actuelles sont invalides, donc il faut soit choisir des timestamps une fois que tu sais quand tu vas la lancer, soit laisser None pour les définir à une période après le lancement.
Ça aiderait d’ajouter des commentaires avec les unités (seconde, bloc, session) parce que là c’est dur à lire (les commentaires sont dans le code Rust mais comme il y a 15 structs différentes pour les configs c’est long à retrouver).
ok pour les fichiers gdev, sauf pour first_ud qui est en timestamp comme dit tuxmain
je me rends compte qu’il n’y a pas de “block number” dans le fichier g1-data, ce sera pratique d’avoir le bloc v1 précis auquel les données ont été extraites
ok pour le comité technique
ok pour que tu lances en solo et qu’on rejoigne après en publiant no session keys avant
la sudo key, ce sera pratique que ce soit une clé qu’on se partage entre nous, mais on pourra la changer avec le comité technique si besoin
bonne idée de passer en yaml pour avoir des commentaires dedans !
J’ai initié la MR!195. Il y a déjà la conversion YAML et quelques commentaires.
Comme je ne vais pas avoir le temps d’y toucher avant ce soir, je vous invite à y contribuer directement si vous souhaitez faire avancer le sujet.
Vous pouvez tester avec :
cargo run -- build-spec --chain=gdev_live --raw > gdev-raw.json
L’avantage de cette commande est qu’elle affiche des logs d’informations sur le paramétrage, notamment en convertissant les valeurs en jours pour bien se rendre compte de ce que l’on fait :
2023-11-17 22:51:55 currency parameters:
- existential deposit: 1 ĞD
- currency decimals: 2
- membership validity: 73 days
- certification period: 24 hours
- certification validity duration: 146 days
- smith membership validity: 73 days
- smith certification validity: 146 days
- required certifications: 3
- smith required certifications: 3
- max certifications by issuer: 100
- money growth rate: 4.88% every 24 hours
- UD creation period: 4 hours
- distance percent of required referees: 80%
- distance max depth: 5
Les données Ğ1 sont celles d’aujourd’hui 08h15 environ.
Le build ARM64 ne semble pas être passé, je relance.
Je n’ai pas pu tester l’image Docker AMD64, je vous laisse ce soin car je n’ai déjà plus de temps pour aujourd’hui (cc @Pini si tu passes par là pour vérifier).
Édit : les images Docker ne sont pas fonctionnelles, nous allons les reconstruire.
Edit 2 : c’est bon ! les images AMD64 et ARM64 fonctionnent toutes les deux, j’ai pu tester :
Quant à la télémétrie, d’abord il faut t’assurer de voir des logs avec un n° de bloc supérieur à 4,000 (désormais, vu que la chaîne avance). Ensuite, et seulement ensuite, se montrer patient car la télémétrie affiche facilement le message :
Super ! Il va y avoir pas mal de travail pour bien profiter de ce réseau, on pourra en discuter ce soir. Je vois que tu as publié les specs au format raw, mais il me manque les specs au format json pour démarrer l’indexeur.
Est-ce que tu aurais le bloc précis ? Ce serait intéressant comme info si jamais on doit debugger la migration. Et est-ce qu’il y avait des messages de warnings comme des certifications expirées ? Ce serait bien d’avoir le fichier g1-data.json aussi ^^
Il y a plusieurs issues sur Polkadot/Substrate à propos d’OOM ou de fuites mémoires mais seulement dans certaines phases de consensus, et jamais avec ce message. J’essaie de trouver d’où ça vient mais il faudrait arriver à installer valgrind ou lldb en arm64 (les dépôts raspbian bullseye sont uniquement en armv7).
Edit: C’est dans sc_service::new_full_parts, à cause du backend db. D’ailleurs ne comprends pas pourquoi les builds armv7 marchent puisque parity-db ne supporte que x86-64 et aarch64.
Edit: Finalement ça marche après suppression de l’ancienne db. C’est tout de même un bug de parity-db.
Il y a un problème chez moi avec la commande pour purger la chaîne :
Dans le container, /var/lib/duniter pointe sur mon dossier de données contenant chains/gdev/paritydb/full et pas .local/share/duniter/chains/gdev/paritydb/full
docker exec -ti home_duniter_validator.1.nalo348fqf89gavs2joq40c48 duniter purge-chain --chain=gdev
Are you sure to remove "/var/lib/duniter/.local/share/duniter/chains/gdev/paritydb/full"? [y/N]: y
"/var/lib/duniter/.local/share/duniter/chains/gdev/paritydb/full" did not exist.
Dans telemetry, je ne vois que mes deux nœuds en 0.7.0. Et seul le validator avance sur une nouvelle chaîne de blocs, le RPC reste sur l’ancienne…
Je préfère qu’il soit dans la release plutôt que les fichiers d’input, puisque précisément ce n’est pas un fichier d’entrée mais un fichier intermédiaire généré par la CI dans son processus de création de la release.
Tu as raison, je vais éditer mon post plus haut, il faut lancer avec l’option -d /var/lib/duniter :
Je ne comprends pas tout à fait comment fonctionne la CI, mais a priori on ne publie les specs qu’une fois (au démarrage d’un réseau) alors qu’on peut faire des publications de runtime régulièrement (pour mettre à jour le réseau). Est-ce que comme tu l’as fait ces fichiers seront ajoutés à chaque release de runtime ou uniquement au démarrage d’un nouveau réseau ?
Chouette, facile, à retenir en plus ><
12 certifications expirées (normal en 30 minutes)
5319 adhésions expirées, pas la peine de les afficher toutes, uniquement les adhésions qui n’étaient pas expirées au bloc de l’export
actual monetary_mass (8,457,743,556) and initial_monetary_mass (8,457,771,775) do not match soit 28219 de différence, ~ ok pour 282 Ğ1
Comme pour l’instant nous sommes susceptibles de redémarrer régulièrement le réseau, la CI builde tous les fichiers à chaque release. Ensuite libre à nous ensuite de mettre à jour les raw-specs dans le code (étape 3) puis de relivrer une image Docker du Client (étape 4, voir le détail des étapes).
Mais effectivement à terme, la plupart des fichiers ne seront plus à livrer.
et tu es bien sur le client 0.7.0, il faut que je le fasse aussi prochainement, j’ai démarré la GDev à partir d’un build Docker local.
