Je vais voir pour industrialiser un peu le processus de démarrage d’une Ğx, d’abord pour la ĞDev mais aussi en vue des ĞTest et Ğ1, avec une documentation plus à jour.
py-g1-migrator est trop orienté Ğ1 actuellement.
Et côté duniter-v2s, il pourrait y avoir quelques contrôles supplémentaires sur build-spec notamment pour vérifier que les délais utilisés un peu partout sont cohérents. J’ai vu qu’il y avait déjà un contrôle sur le nombre de certifications par exemple.
Après réflexion, je suggère que nous mettions tout le nécessaire à démarrer une nouvelle monnaie dans le process de CI des branches de release.
Concrètement :
dans le stage “deploy” rajouter un job “deploy-runtime” qui se chargerait de lancer la commande cargo xtask release-runtime <version> ET de publier le fichier gdev_runtime.compact.compressed.wasm sur la page de release
(dépend de “deploy”) créer un nouveau stage manuel “genesis config”, avec un job par Ğx (ĞDev, ĞTest et Ğ1) : génère le fichier de configuration du Genesis et le publier sur la page de release
(dépend de “genesis config”) créer un stage “raw-spec”, avec un job par Ğx (ĞDev, ĞTest et Ğ1) : génère les raw-spec, en prenant comme inputs le genesis config ET le runtime généré, et le publier sur la page de releases
Détail de chaque étape
Etape 1
Cela revient à exécuter la commande cargo xtask release-runtime <n° de version> mais en uploadant en plus le fichier Wasm.
Etape 2
Dépend de py-g1-migrator pour obtenir les données de la Ğ1, car nous les utilisons pour que même en ĞDev ou ĞTest, nous ayons une toile de confiance et des comptes au plus proche de la Ğ1 (ce qui permet de détecter des bugs qui ne surviendraient qu’en Production).
py-g1-migrator dépend lui-même d’une BDD Duniter v1.
Ce que je propose : que dans duniter-v2s nous maintenions des fichiers gdev.json, gtest.json et g1.json, qui contiendraient les paramètres de la monnaie et la toile smith, et seraient mergés dans le résultat de py-g1-migrator.
En effet ce sont les seuls parties spécifiques à la fois à Duniter V2S et aux monnaies de test qui ne peuvent pas être extraites de la Ğ1 : je trouve plus logique et pratique que ces fichiers soit dans le code source de Duniter V2S plutôt que dans py-g1-migrator.
Concernant la BDD Duniter v1 : celle-ci serait déposée manuellement de temps en temps sur un lien HTTP public que la CI pourrait interroger afin d’être exploitée par py-g1-migrator.
Etape 3
Reviendrait à exécuter la commande suivant (exemple gdev) :
Mais si quelqu’un se lance dedans alors je vais faire tout mon possible pour l’aider !
Oui, il y a dedans du travail de réorganisation, commentaire de code, correction de bugs à conserver. Il y a aussi des modifications spécifiques à la ĞTest comme l’adaptation au format du genesis ĞTest, notamment le nom des champs (“index, owner_key, membership_expire_on, next_cert_issuable_on, certs_received”).
Ces modifications vont de pair avec la branche hugo-gtest sur duniter-v2s. J’ai développé les deux en parallèle pour vérifier les entrées côté duniter et produire une sortie complète et cohérente côté py-g1-migrator.
Voilà pourquoi ce n’est pas mergé pour l’instant.
Et d’ailleurs, il y a aussi des modifications côté indexeur pour qu’il soit compatible avec les deux formats de genesis. (cf index-genesis-gdev.ts et index-genesis-gtest.ts dans src/services · master · nodes / duniter-indexer · GitLab).
Il y a un todo ligne 116 à ce propos. Si je comprends bien, l’idée de faire ça est qu’on puisse télécharger le runtime depuis gitlab pour le soumettre sur la chaîne ?
Pour le reste, tout me semble ok. Et à mon avis on ne devrait rien mettre concernant les monnaie sur la branche master, et avoir une branche dédiée par réseau (gdev6, gdev7, gtest, g1). Ça éviterait de trop se mélanger les pinceaux et on pourrait utiliser le nom de branche pour générer l’image docker, par exemple duniter/duniter-v2s:gtest serait le "latest` sur le réseau gtest en cours (cf discussion Release new image with ĞDev5 chainspecs - #46 by Moul).
J’aimerais sortir ça de py-g1-migrator. Pour moi c’est Duniter V2S via generate_genesis_data qui doit faire le travail, py-g1-migrator ne devant faire que ce que son nom suggère : extraire les données de la Ğ1 pour les mettre à disposition de Duniter V2S dans un format simple d’exploitation.
Mais donc on pourrait déjà merger ta branche pour que je travaille sur une base de code à jour.
Tu veux dire hugo-dev ?
Si oui il faudrait que tu la rebase sur master (git rebase master) pour que l’on recommence le processus de livraison de la runtime-600.
Est-ce que tu veux bien faire ça en priorité ? Comme je dois me baser dessus pour le travail de CI, ça va vite me bloquer je pense.
OK ça aussi je propose que ce soit Duniter qui le gère via generate_genesis_data ou code alentours, en produisant à la fois les ChainSpec ET un fichier à destination des indexeurs.
Ah oui, je ne l’avais pas vue.
Oui pour le mettre dans la ChainSpec, au final cette dernière n’est que la fusion du genesis config + le runtime : ces fichiers sont générés indépendamment et devraient pouvoir être exposés dans la page de release.
Une release contiendrait donc :
liste des changements (déjà fait, mais ne fonctionne pas très bien j’ai l’impression)
release_notes (hash du setCode, etc.) (déjà fait)
runtime (commun à toutes les Ğx)
un fichier “<gx>_genesis_config.json” par monnaie à destination de Duniter pour la commande build-spec
un fichier “<gx>_raw_spec.json” par monnaie à destination de Duniter
un fichier “<gx>_indexer_spec.json” par monnaie à destination des indexeurs
Il n’y a pas de réseau “gdev6” ou “gdev7”, mais juste une ĞDev qui est remise à zéro de temps en temps. Au contraire je mettrais tout sur master, c’est-à-dire gdev, gtest et g1.
Et à chaque release, dans les stages de la CI, on crée un job manuel pour chaque monnaie. Job qui pousse :
le GenesisConfig de ladite monnaie
sa ChainSpec résultante
et la nouvelle image Docker (par ex. duniter/duniter-v2s-gdev:latest, je suis plutôt de l’avis de @Pini sur la nomenclature où le tag est latest, c’est le standard Docker).
Le job serait manuel car une release n’a pas forcément vocation à déployer une remise à zéro d’une monnaie, c’est même plutôt l’exception que la règle avec Substrate.
C’est d’autant plus logique, je trouve, de maintenir ces fichiers gdev.json, gtest.json et g1.json dans le dépôt Duniter qu’il y a déjà dans les specs des données “live” : les bootnodes.
On peut mettre la limite où on veut, l’idée est de pouvoir éditer les données de test facilement pour les besoins des tests (exemple pour l’indexeur : Files · master · nodes / duniter-indexer · GitLab).
Mais c’est vrai que le schéma :
base de données v1
outil pour exporter les données v1 dans un format 1 (py-g1-migrator)
outil pour convertir le format 1 dans un format 2 (parsing du genesis duniter)
outil pour utiliser le format 2 (genesis builder duniter)
pourrait être simplifié.
Oui, en effet, hugo-gtest est une branche local pas très loin de hugo-dev. Je vais rebaser sur master en priorité cette semaine.
Le runtime ĞDev est différent des runtime ĞTest entre autres parce qu’il utilise duniter-test-parameters pour pouvoir changer plus facilement certains paramètres en cours de route.
J’ai rebasé hugo-dev sur master. Un détail : dans time-base UD, tuxmain a renommé “first_ud” en “ud” et ajouté “first_ud” pour la date du premier DU. J’ai donc adapté le format du genesis en fonction. Le champ que j’avais appelé first_ud_value correspond maintenant à ud et il y a un champ additionnel first_ud. Voilà une incohérence que je préfère te signaler avant que tu tombes dessus.
On voit ça dans la macro custom pallets_config! (gdev, gtest, définition), le runtime gdev utilise la pallet duniter_test_parameters plutôt que des valeurs hardcodées. Elles peuvent être modifiées avec un simple call en root et donc ne nécessitent pas un runtime upgrade pour être modifiées.
Je pense que c’est dans l’idée de ce post (Liste des paramètres (protocolaires) de Duniter-v2s) que elois a implémenté cette pallet pour faciliter la modification des paramètres en phase de test. Mais au début il n’y avait pas de README par pallet ni par runtime, je les ai ajoutés par rétro-ingénierie donc c’est peut-être pas toujours pertinent.
Est-ce que supprimer duniter_test_parameters nous soulagerait d’une complexité encombrante, faciliterait significativement les contributions et la compréhension ? Pouvoir modifier facilement certains paramètres semble utile.
Je dirais que oui c’est encombrant, indépendamment de ma tâche en cours : cela crée dans le code plusieurs sources de vérité sur la provenance de la valeur des paramètres de la monnaie (confusion, déjà observée chez @HugoTrentesaux et moi-même à nos débuts) et nous éloigne du scénario standard où ces paramètres ne sont pas modifiables (risque de non-test ou mauvais tests).
Si les paramètres sont modifiables uniquement par Runtime upgrade, alors autant se placer tout de suite dans ce cas là sauf intérêt supérieur à pouvoir les modifier à chaud. Or, d’une part nous sommes tout proche d’une GTest, d’autre part je ne vous ai jamais vu utiliser cette fonction sur la Gdev.
Oui, sans problème, et n’hésite pas à me ping dès qu’il y a quelque chose de pas clair, je suis dispo 100% du temps et souhaite limiter les frictions au maximum pour que tu puisses avancer sans encombre.
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’imageparitytech/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
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.
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.
merci, je poursuis !