Je ne suis pas d’accord avec ça. Exemple concret :
Alice reçoit cinq certifications et devient membre
une année après, Alice certifie Bob
une année après, les certifications reçues Alice expirent et Alice perd le statut de membre
deux mois après on souhaite migrer la Ğ1 (il faut compter la certification de Alice vers Bob)
Donc pour le genesis Ğ1v2 il faut :
créer l’identité Alice (identity index = 1)
créer l’identité Bob (identity index = 2)
ajouter la certification Alice vers Bob (1 → 2) qui expire dans dix mois
retirer l’identité Alice (ses métadonnées et le nom “Alice”).
Autrement dit, les identités non membre ayant moins de 5 certifications actives reçues au moment de la migration (mais ayant émis des certification) doivent être incluses puis exclues.
Il faut filtrer les certifications dont la date d’expiration est antérieure à la date de migration (ne garder que celles toujours actives).
J’ai renommé ce repo, déplacé dans le groupe tools, ajouté licence et copyright.
Cela dit, je me demande si je vais pas recréer le dépôt de zero (init commit) car:
J’ai ajouté le build dex qui fait 29 Mo, je peux l’enlever du dépôt et faire en sorte de le télécharger automatiquement depuis quelque part lors de l’exécution de generate_dex_data.sh si le build n’existe pas localement.
Je pourrais déplacer le json final output/gtest.json (5.3Mo) ailleurs, genre dans output/default/ pour ne pas interférer avec les build générés au niveau du git.
Je veux que ce json soit présent simplement pour que chacun puisse y accéder comme Maaltir le fait, sans avoir à cloner ni exécuter quoi que ce soit. Je sais que normalement pour bien faire, ces fichiers générés ne devraient pas être présent dans le repo, mais avez-vous une meilleurs idée ?
Je peux déplacer intput/*json (74Mo) dans input/default/, également pour ne pas interférer avec les build locaux et le git. Je veux aussi que ces json soient présent de manière a pouvoir skip l’étape 1 pour ceux qui n’ont pas de profile Duniter localement.
Je peux fermer ce topic brouillon et en ouvrir un nouveau « Ğ1 data migration » qui présente mieux la chose et puisse ouvrir des discutions plus concrètes sur le format de données genesis v2s.
Je dis tout ça car le .git fait déjà 111Mo inutilement.
Qu’en pensez-vous ?
Je suis preneur d’avis et conseils sur ces sujets de design de repo (tout en prenant en considération mon besoin de garder les json générés par defaut quelque part comme je l’ai expliqué).
Je ne connaissais pas, ça à l’air super, j’ai essayé un peu, mais le soucis pour moi avec ça est qu’on se retrouve avec des fichiers du type:
$ cat input/blocs.json
version https://git-lfs.github.com/spec/v1
oid sha256:c9a89582cc2273240c46dbc4439e4d6c2caca44199662ee37e20573dfb3ddf95
size 28742754
et le fait que:
Il ne faut pas oublier que chaque personne qui interagira sur le projet devra suivre la procédure d’installation de Git LFS sur son environnement.
Tu peux générer le JSON avec la CI Gitlab en tant que fichier de Release. La CI de Gitlab se chargerait de télécharger Dex et de générer le JSON dans une Release.
Ou bien le téléverser manuellement sur le wiki Gitlab ou dans les Releases.
En effet ça me semble une meilleur approche étant donnée que ce sont effectivement des artefacts de release.
Pour le build dex par contre je pense garder mon idée de juste wget depuis un de mes serveurs dans le bash script qui va bien, c’est 2 lignes.
par contre faut que je comprenne comment config la CI gitlab… J’avoue que si quelqu’un qui connait un peu pouvais contribuer là dessus j’aimerai beaucoup. Sinon je mettrais les mains dedans.
Mais je rappel que pour le step 1 avec dex, ça nécessaite d’avoir le dossier ~/.config/duniter/duniter_default/ « à jours » localement, ça me semble difficile depuis la CI gitlab non ?
Ou a la limite c’est ce dossier qu’il faudrait ajouter en git LFS peut être ?
On peut bien sur définir un chemin custom de ce dossier avec l’option ./dex -p /path/to/duniter/profile
Après @vit si t’es chaud pour te réapproprier ce projet de manière générale sens toi libre
Ah oui, j’ai peur que recréer les données d’un nœud en CI soit long et gourmand en ressources… Je n’avais pas pensé à ça.
Mais je pense que les besoins d’exposer le JSON en public pour analyse et tests doivent être séparer du dépôt git. Un dépôt Git doit contenir que le nécessaire à compiler puis exécuter. Faisons cela, puis ensuite voyons comment publier le JSON. Si on peut automatiser sa génération en CI c’est bien. Sinon on devra le générer localement puis le téléverser quelque part pour publication.
Bon je regarde ça demain et ferai des propositions.
Je pense qu’un cron dex qui sort les json une fois par jour et les publie sur un serveur peut faire l’affaire. Je peux m’en occuper un de ces jours. Ensuite py-g1-migrator fait sa tambouille à partir de ces json. CI gitlab ou script cron, ça me paraît à peu près équivalent en terme de résultat.
Pas en terme de coût, on va pas lancer un noeud duniter, attendre qu’il sync avant de continuer chaque CI !
Ta proposition de publier les JSON Dex me semble idéal.
Il ne reste que le json genesis final à traiter en CI, et pas besoin de Dex pour ça, juste python
Bah écoutez c’est cool, @HugoTrentesaux fait ça, comme ça @vit peut virer dex et le dossier intput (le step 1 en fait) du repo, et juste config la CI pour ./main.py
Comme ça après ça, on pourra recréer le dépot git, fermer ce topic de forum et en ouvrir un nouveau
Pas nécessairement, du moins ce que tu proposes n’est pas le plus simple en termes d’implémentation coté duniter-v2s.
Je vous recommande plutôt d’ajouter simplement au genesis des “extra certs” sans identités associées, mais qui réservent quand même un identityIndex pour être prises en compte dans la règle de distance.
Ça permet de ne pas avoir à gérer d’identités bizarres coté blockchain que le runtime actuel ne sait pas gérer, et puis intégrer quelque chose au genesis pour le retirer juste après (au bloc 1) me semble être un très mauvais design, pas du tout compatible avec l’esprit de substrate.
Le plus simple coté runtime est de modifier le genesis build de la pallet identity pour autoriser le IdtyIndex à commencer à un nombre configurable (au lieu de zéro actuellement). vous pourriez alors configurer ce nombre au nombre d’identités qui n’existe plus mais qui ont encore des émises actives.
ce n’est pas une identité bizarre, juste un IdtyIndex qui ne correspond à rien (ni métadonnées, ni nom), c’est déjà comme ça que sont représentées les identités retirées d’après ce que j’ai compris du code. Actuellement dans Duniter on peut retirer une identité alors qu’elle a encore des certifications émises, ça ne pose pas de problème, vu que l’IdtyIndex ne sera jamais réutilisé.
Et je ne compte pas les retirer juste après, mais au bloc zéro directement. Ça revient un peu à ce que tu proposes avec le nombre d’identités configurables, mais ça permet de garder un IdtyIndex qui a un peu de sens, au moins historique.
Pour info, ça fait longtemps que j’utilise un IdtyIndex dans DataJune, on peut tout simplement réutiliser celui là qui correspond à l’ordre d’apparition dans l’archive json de la blockchain que j’ai utilisée pour ça.
PS:
C’est peut-être inutile, mais ça me ferait plaisir qu’en interne, les IdtyIndex des 59 identités du bloc zéro soient numérotées de 1 à 59
Donc soit remplacer le map json par un tableau et l’ordonner par joined_on, soit ajouter dans le json le joined_on, mais ça serait bizarre puisque substrate n’utilise pas cette donnée par la suite. Donc je suis plutôt pour la première solution, ce qui a aussi l’avantage de faciliter le debug (idty_index = indice dans le json).
J’ai ajouté un dossier custom/ où vous pouvez facilement ajouter des identités customs, définir groupe smith, comité tech et les paramètres de la monnaie.
Il faut mettre ça avec un gros warning dans le readme de py-g1-migrator, sinon on risque de prendre ça pour acquis ><
Ah non en fait alors
Ah mais ça par contre il faut le mettre
Bref, je relis ce sujet et je me rends compte qu’il s’est passé beaucoup de choses, j’ai pas été tellement utile sur ce coup. Mais maintenant je suis en mesure de changer le parsing du genesis. À chaud comme ça je dirais :
ce serait vraiment chouette de conserver les idty index de la v1. En terme de suivi c’est mieux que d’avoir des “extra certs” avec un mapping implicite
je pense qu’on peut mettre les identités v1 dans le genesis avec un removable_on à zéro, ça permet de garder une trace de la v1 dans le genesis
Pourquoi est-ce que tu n’appliques pas la fonction prune_identities au bloc zéro ?
fn on_initialize(n: T::BlockNumber) -> Weight {
if n > T::BlockNumber::zero() {
Self::prune_identities(n)
} else {
0
}
}
Ça me paraît simple d’ajouter les identités avec un expire_on: 0 et removable_on: 0 de telle sorte que l’adhésion expire dès le bloc zéro et que l’identité correspondante puisse être retirée dès le bloc zéro.
Peux-tu détailler ? Est-ce parce que le storage est écrit dans le genesis et que la fonction on_initialize ne s’y applique pas?
