Industrialiser le démarrage d'une nouvelle Ğx

Nodes Duniter-v2s
, ,
3

Ce serait en effet super d’automatiser ce processus avec une CI ! Je ne m’étais pas lancé dedans pour plusieurs raisons :

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 faut qu’on discute de ces différences et si ça vaut le coup de le conserver, j’ai ajouté ce point à l’ordre du jour de la Visio dev -- mercredi 20 septembre 2023 -- 21h.

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).

4

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. :slight_smile:
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.

2 Likes
5

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.

ok

ok

ok

2 Likes
6

Je veux bien contribuer à implémenter la partie CI une fois que les scripts sont au point.

3 Likes
7

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.

1 Like
8

Autre incohérence que tu pourrais rencontrer : la masse monétaire totale. Cf ces deux sujets :

1 Like
9

As-tu un exemple ? Au pire il pourra y avoir 2 runtimes : un dev et un prod, mais je suis curieux de savoir où cette palette est utile.

10

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.

11

Si c’est juste pour ça, nous pourrions la retirer. Qu’en penses-tu ? @tuxmain aussi ton avis ?

12

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.

1 Like
13

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.

4 Likes
14

Hello Hugo, est-ce que je peux merger ta branche sur la master de py-g1-migrator ? Je ferai les modifications nécessaires ensuite.

1 Like
15

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.

2 Likes
16

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
17

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. :confused:

18

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
19

Ah mais oui Moul, bien vu ! Je vais essayer :slight_smile:

edit : yes, ça a fonctionné :100: :+1: merci, je poursuis !

edit 2 : hop pour les plus curieux, release produite par la CI avec le Runtime ĞDev :slight_smile: (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
20

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
21

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 “:warning:” pour les incohérences détectées par le migrator.

J’ai notamment fait le tour des sujets qui parlent de ça :

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
22

Merci pour cette réponse très complète. :slight_smile:

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