Merci.
Tu as supprimé ta branche hugo-dev ? Je peux faire sans, mais il y avait du code modifié et non mergé.
edit : ah non c’est sur master. Merci.
1 Like
Je sèche un peu sur le job de CI qui doit appeler le srtool. En fait la CI ne monte pas le volume sur cette instruction :
docker run -i --rm -e PACKAGE=gdev-runtime -e RUNTIME_DIR=runtime/gdev -v "$(pwd):/build" paritytech/srtool:1.62.0 build --app --json -cM
Le résultat est visible sur ce job : create_release (#113177) · Jobs · nodes / rust / Duniter v2S · GitLab
Le srtool fini par me dire “No such file or directory”, ce qui est logique.
C’est une histoire de Docker mais ça me dépasse, @immae as-tu une idée ? Vu que je passe par Kepler sur ce job. J’ai pourtant bien vu que le mode “privileged” était utilisé dans la conf Nix.
A priori la solution c’est de monter le path de l’hôte (Kepler) plutôt que la path dans le conteneur du job dans l’instruction ci-dessus. Mais je ne sais pas comment l’obtenir. 
Y’a-t-il une raison particulière pour laquelle tu fais du dind (Docker in Docker) ? Ça complexifie la tâche.
Pourquoi ne pas spécifier l’image paritytech/srtool:1.62.0 pour ce job ?
Le contenu du dépôt duniter-v2s est automatiquement “monté” et devient accessible dans l’image paritytech/srtool et tu pourrais lancer la commande srtools sur le dépôt duniter-v2s.
Exemple à peu près :
create_release:
stage: test_deploy
image: paritytech/srtool:1.62.0
rules:
- when: always
variables: # pas sûr que ça donne des variables d’environement, sinon utiliser les exports ci-dessous
PACKAGE: "gdev-runtime"
RUNTIME_DIR: "runtime/gdev"
script:
- export PACKAGE=gdev-runtime; export RUNTIME_DIR=runtime/gdev; srtool build --app --json -cM
artifacts:
name: "Artifact 1"
paths:
- resources/
- runtime/gdev/target/srtool/release/wbuild/gdev-runtime/
expire_in: 1 day
tags:
- kepler
4 Likes
Ah mais oui Moul, bien vu ! Je vais essayer 
edit : yes, ça a fonctionné 
merci, je poursuis !
edit 2 : hop pour les plus curieux, release produite par la CI avec le Runtime ĞDev (et le fichier de sortie de srtool, pas indispensable mais peut être utile pour contrôle). Cette release sera écrasée dans les prochains jours avec les éléments manquants, mais c’est pour montrer que les choses avancent.
5 Likes
J’en suis rendu à reprendre cette partie du travail pour la mettre dans le pipeline commun (méthode gen_genesis_data qui produit un format pivot) côté duniter-v2s.
Te souviens-tu du niveau d’avancement que tu avais atteint sur cette partie ? J’ai un gros travail de refactoring car effectivement, les Genesis ĞDev et ĞTest n’étaient vraiment pas formés de la même façon. Savoir où tu en étais m’aiderais à savoir si je dois être minutieux ou si avancer sur les grandes lignes suffirait.
1 Like
Voici ce que je note côté py-g1-migrator :
- ajouter la date de versement du premier DU ajouté par tuxmain dans !178
- récupérer l’adresse de la trésorerie pour déplacer la monnaie ignorée
- rendre le préfixe ss58 des addresses paramétrable (42 pour les réseaux de test, 4450 pour la Ğ1)
- s’assurer que la quantité de monnaie dans les comptes correspond à la masse monétaire
- vérifier que la conversion timestamp → nombre de blocs est cohérente
Et à part ça, il faut tenir compte de la sortie des print avec un “
” pour les incohérences détectées par le migrator.
J’ai notamment fait le tour des sujets qui parlent de ça :
- Adapter py-g1-migrator pour la migration Ğ1
- What's needed to start a ĞTest network
- Incohérence dans les données? -- certifications expirées
- V2S: Ğ1 data migration (g1-migrator)
- Date de création du DU
- Quantité de monnaie sur Duniter
- Total issuance vs monetary mass
- g1-migrator
Côté Duniter-v2s, je n’ai pas trop documenté à part dans les commentaires du code parce que je m’adaptais à ce que je faisais sortir du migrator. Mais de mémoire et en regardant le code :
- s’assurer que la trésorerie ne crée pas de monnaie au genesis (elle doit être mise à existential deposit minimum, donc si elle est à zéro de la monnaie est ajoutée)
- s’assurer qu’il y tous les check au genesis nécessaires à ne pas avoir d’incohérence de storage
Et donc pour répondre à la question, je dirais que le niveau d’avancement côté gtest est assez poussé, il faut être un peu minutieux dans les refactoring et lire les commentaires dans le code. Par contre côté gdev il faut pas hésiter à tailler dans le gras, j’ai quasiment pas touché à ce qu’avait fait elois pour éviter de casser les tests qui étaient basés sur cette manière de parser le genesis, mais le but de la factorisation étant de rapprocher les tests des conditions réelles, c’est le moment de casser des trucs.
4 Likes
Merci pour cette réponse très complète.
Je vais donc plutôt partir du code présent dans le fichier gtest_genesis, tout en le faisant rentrer dans le format pivot, puis j’adapterai ce qui tourne autour de la ĞDev. Il y a quand même beaucoup des similitudes, ça devrait bien se passer.
Puis ce sera travail itératif d’incorporation de toutes les règles que tu viens de mentionner, et du transfert des règles qui étaient dans py-g1-migrator vers Duniter afin de centraliser les contrôles auprès du code qui fait foi (le Runtime).
Je ne me rendais pas compte à quel point il restait du travail sur cette partie migration.
1 Like
Pour suivi : j’ai pratiquement terminé les développements, il me reste des finitions.
Restera ensuite une revue de code à effecuter par tuxmain et/ou Hugo, puis nous pourrons tenter de relancer une ĞDev. A mon avis, tout cela sous 15j.
5 Likes
Traité : est défini dans le fichier de conf de chaque monnaie (gdev.json, gtest.json).
Je considère que c’est fait, au sens où il n’y a – pour l’instant – aucune monnaie à transférer vers la Trésorerie selon moi. Si cela devait toutefois changer, il suffirait d’adapter la fonction gen_genesis_data.
N’est plus nécessaire : les comptes Ğ1v1 sont importées bruts (clé publique Ed25519) car Substrate ne fait qu’extraire les clés publiques et ne contrôle pas les adresses pour le Genesis.
Fait, on voit que ce n’est pas le cas. Reste à voir d’où provient ce delta.
La conversion se fait côté Substrate, et un test couvre ce cas de figure.
Les seules sorties qui méritent encore de l’attention selon moi sont :
⚠️ Pseudo1 → Llorens cert expired between export and start
⚠️ Pseudo2 has received only 1 certs, disabling it
Je vais voir pour les déplacer côté Duniter.
OK.
Par conséquent, reste à faire :
Ne pas filtrer les certifications ou identités côté py-g1-migrator mais côté Duniter
s’assurer que la trésorerie ne crée pas de monnaie au genesis (elle doit être mise à existential deposit minimum, donc si elle est à zéro de la monnaie est ajoutée)
s’assurer qu’il y tous les check au genesis nécessaires à ne pas avoir d’incohérence de storage
Adapter py-g1-migrator pour la migration Ğ1
What’s needed to start a ĞTest network
Incohérence dans les données? – certifications expirées
V2S: Ğ1 data migration (g1-migrator)
Date de création du DU
Quantité de monnaie sur Duniter / Total issuance vs monetary mass
g1-migrator ==> seulement le sujet V2S: smooth gradual migration (clients and indexers side)
Pas sûr que je traite tout dans la même MR, nous verrons.
5 Likes
Il me reste deux sujets :
- la masse monétaire “manquante” : pas nécessaire pour redémarrer la ĞDev, et sujet de désaccords (voir [Reprise Ğ1] Monnaie manquante - #13 by cgeek), mais surtout non bloquant pour la ĞDev 600
- la création d’un Genesis pour l’indexeur de @ManUtopiK à partir du GenesisData : là-dessus je ne sais pas bien ce qui est attendu, en tout cas l’emplacement pour réaliser le mapping entre GenesisData et le json à fournir à l’indexeur se trouve ici. Voici un exemple d’export résultat :
indexer.json.zip (3,8 Mo) ce fichier peut être re-généré une fois la ĞDev lancée donc là aussi non bloquant pour la ĞDev 600
Bref pour moi la tâche arrive à sa fin, je vais peaufiner les 2-3 TODOs que j’ai laissé dans le code, nettoyer le fichier .gitlab-ci.yml puis tester tout cela de bout en bout, créer une release et lancer une ĞDev locale.
Vous pouvez déjà commencer à inspecter la MR!182 si vous le souhaitez.
6 Likes
Pour la création d’un Genesis pour l’indexer, il faut extraire de la v1 toutes les transactions avec le message, toutes les certifications des membres… et je me souviens plus. Il faut que je regarde ce qu’avait fait @poka.
J’ai regardé dans le indexer.json.zip, il n’y a pas les certifications ?
Sinon, merci à toi ! Génial de voir que ça avance
1 Like
A regarder py-g1-migrator, je dirais que l’indexer mange deux fichiers :
gdev.json: un fichier de Genesishistory.json: un fichier d’historique des transactions
Si dans le champ certs_by_receiver, qui associe à l’index du receveur une map issuer → dateExpiration. Mais on peut facilement lui donner une autre tête, en mettant les pseudonymes, les clés publiques ou encore les adresses. A toi de me dire
3 Likes
Ah, je n’avais pas vu le champ !
Oui, l’indexer a besoin de ces 2 fichiers. Les derniers en date que l’on a utilisés sont là :
1 Like
OK, je vais reprendre leur format dans ce cas. Si je mets tout dans un seul fichier indexer-gdev.json par exemple, ça te va aussi ?
Oui, carrément ! Je m’adapte
1 Like
Petit inconvénient de forcer ceci dans le format du genesis : on ne bénéficie plus de la checksum intégrée à l’adresse. Embêtant pour les fichiers de test dans lesquels c’est pratique de mettre les adresses plutôt que les pubkeys “nues”.
Tu parles des fichiers Cucumber ?
Oui, par exemple, ou quand on veut un fichier custom de dev local avec Alice Bob et compagnie.
Dans ce cas on peut laisser les deux champs : pubkey et address, les deux étant optionnels et j’ajoute un contrôle dans gen_genesis_data pour qu’un seul des deux champ soit renseigné.
Je vais voir, j’ai encore des vérifications à faire avant de me repencher sur ce genre de cas.
1 Like
Voilà une nouvelle version, qui ressemble beaucoup plus à l’ancien gdev.json avec une nouvelle entrée "transactions_history" : https://dl.cgeek.fr/indexer.json.zip
Le fichier JSON fait 85Mo 
2 Likes