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.
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.
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.
Il me reste deux sujets :
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.
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
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 transactionsSi 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
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à :
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
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.
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
La branche a été mergée. Petite présentation du nouveau processus de livraison que nous utiliserons pour prochainement relancer la ĞDev (700).
release/runtime-<numero>
La création se réalise en créant une branche depuis master release/runtime-<numero>
où <numero>
est la version du Runtime. Exemple : release/runtime-700
.
Une fois la branche poussée, GitLab CI crée un pipeline comme le suivant qui s’affiche et s’exécute jusqu’à l’étape bloquante create_release
:
On voit ici tous les jobs impliqués, leurs liens de dépendance et ceux qui nécessitent une action manuelle symbolisée par l’icône .
Les dépendances sont matérialisées par les lignes grises (ou bleues au survol d’un job). Dans la capture ci-dessus je survole create_release
.
Une fois lancé le job create_release
, la page de release et le tag (ici runtime-700
) sont créés.
La release contient les informations suivantes.
Ce sont les livrables par défaut de toute release, même si certains ne seront pas exploités.
Quoi qu’il arrive, les fichiers de Runtime seront exploités : soit pour faire un Runtime upgrade, soit pour démarrer un nouveau réseau.
gdev_runtime.compact.compressed.wasm
: le Runtime ĞDevgtest_runtime.compact.compressed.wasm
: le Runtime ĞTestCes fichiers ne seront utilisés que si l’on souhaite démarrer ou rebooter une monnaie. Néanmoins, en l’état actuel du développement de Duniter V2, c’est une opération que nous sommes susceptible de réaliser fréquemment donc pour l’instant ces livrables seront produits à chaque fois.
Ces fichiers sont présents dans la page de Release uniquement par soucis de transparence et de vérification. Seuls les fichiers “En sortie” seront directement exploités.
gdev.json
: le fichier de configuration du Genesis pour la spec du réseau ĞDevgtest.json
: le fichier de configuration du Genesis pour la spec du réseau ĞTestgdev_clients-specs.json
: le fichier de configuration du Client pour la spec du réseau ĞDevgtest_clients-specs.json
: le fichier de configuration du Client pour la spec du réseau ĞTestg1-data.json
: le fichier de migration des données de la Ğ1 intégrées à la spécification des réseaux ĞDev et ĞTestLes fichiers de specs :
gdev-raw.json
: la spécification du réseau ĞDev, résultante de gdev.json
, g1-data.json
et gdev_client-specs.json
gtest-raw.json
: la spécification du réseau ĞTest, résultante de gtest.json
, g1-data.json
et gtest_client-specs.json
Les détails des deux Runtimes (bientôt trois avec la Ğ1) produits, un pour chaque réseau :
Si le Runtime doit servir à rebooter un réseau (par exemple redémarrer la ĞDev), alors il y a deux étapes supplémentaires à réaliser.
C’est une pratique courante avec Substrate : publier les chain specs avec le code source du projet.
Une commande xtask
a été créé pour l’occasion. Ici, pour mettre à jours les chain specs du runtime-700
, à lancer depuis la branche de release :
cargo xtask update-raw-specs runtime-700
Cette commande va télécharger les chain specs publiées dans la page de release si celles-ci existent :
Et les pousse dans le répertoire node/specs/
.
Il suffit alors de commiter ces fichiers et de les pousser depuis la branche de release.
Créer ou rebooter une monnaie implique de relivrer le Client, puisque celui-ci se base sur les chain specs pour authentifier la blockchain à laquelle celui-ci va se connecter.
Une fois l’étape précédente réalisée (commiter les chain specs), la CI propose alors deux jobs permettant de builder puis publier les images Docker idoines :
gdev_docker_release_build
: pour builder l’image Docker du Client ĞDevgtest_docker_release_build
: pour builder l’image Docker du Client ĞTestgdev_docker_release_deploy
: pour publier l’image Docker du Client ĞDevgtest_docker_release_deploy
: pour publier l’image Docker du Client ĞDevPetit retour d’expérience suite au redémarrage de la ĞDev réalisé aujourd’hui, notamment pour essayer de projeter le temps d’indisponibilité lors de la migration de la Ğ1 sur Duniter V2S.
Je reprends point par point les étapes que j’ai dû exécuter pour rebooter la ĞDev de zéro avec les données actuelles de la Ğ1.
Environ 1 minute.
Ce processus est assez rapide, mais manuel. Je lance un script chez moi qui copie à chaud les fichiers suivants de Duniter v1 :
data/
g1/
txs.db
Le tout est zippé et mis à disposition sur https://dl.cgeek.fr/public/backup-g1-duniter-1.8.7.tgz
Environ 11 minutes.
Consiste à :
release/runtime-700
ici)create_release
lorsque celui-ci devient disponibleEnviron 1 minute.
Consiste à :
cargo xtask update-raw-specs runtime-700
Consiste à :
g1_docker_deploy
lorsque celui-ci devient disponible1 minute
Consiste à :
Suppose d’avoir préparé en amont la clé du nœud et les clés de session compatibles avec la spec Ğ1.
Cela fait donc un total de ~25 minutes de blocage de la Ğ1 en l’état actuel du processus. Il est sûrement possible de descendre aux environs de 10 minutes en optimisant.
Il faut bien noter que ces temps s’obtiennent en ayant préparé les étapes 2 et 5.
Cela dit, je ne suis pas sûr qu’il soit souhaitable de trop mettre d’énergie dans des optimisations : 25 minutes me semble déjà tout à fait acceptable. Je vous laisse juger.
C’est super que tout ce processus prenne “si peu” de temps ! Et on peut tout à fait lancer un réseau en deux minutes environ :
build-spec --raw
avec un binaire pré-compilé (< 10 secondes)--chain ./gdev-raw.json
(< 10 secondes)Voilà, le réseau est lancé ! Les étapes suivantes vont permettre à d’autres forgerons de rejoindre mais n’ont pas besoin d’être réalisées avant le lancement du réseau.
Certes. Mais le problème de la méthode manuelle, c’est la partie manuelle. Il suffit d’un petit oubli et tout peut partir en vrille, et le gain espéré de quelques minutes peut s’avérer contre-productif.
Personnellement je ne m’y risquerai pas, d’autant qu’il y a plus d’enjeux ailleurs (par exemple, s’assurer qu’il n’y a pas de gros bug bloquant peu après le lancement).
Cela dit, rien n’empêche le jour J d’utiliser les 2 méthodes en parallèle, afin d’avoir la méthode industrielle en solution de repli au bout de 25". Mais bon, je préfère quand même la méthode indus car plus transparent, il y a tout le détail de ce qui s’est passé, davantage vérifiable entre autres.
Je n’ai pas dit que ça devait être manuel, juste qu’on pourrait avoir un processus automatique différent qui utilise un artefact compilé avant.