Sujet pour suivre l’avancement de la production du Runtime 800 qui succède au Runtime 701.
Le Runtime 702 initialement prévu ne verra pas le jour, car nous avons choisi de refondre fortement certaines parties du Runtime au point qu’il est plus simple de redémarrer une nouvelle ĞDev.
Suivi de projet prévu sous 2 semaines.
Pour ce nouveau reboot, je propose :
smith_inactivity_max_duration: 336 deux semaines d’inactivité avant l’exclusion forgeron, ce sera plus pratique pour accueillir des nouveau forgerons (par rapport à 2 jours)smith_wot_min_cert_for_membership: 2 plus pratique pour accueillir de nouveau forgerons (par rapport à 3)technical_committee: ["Pini", "moul", "HugoTrentesaux", "tuxmain", "Maaltir", "vit", "cgeek", "poka"] pour avoir un comité technique plus actif en moyenne (retrait de 1000i100, ajout de Maaltir et poka)Rappel : toutes les issues sont référencées par la Milestone 800 qui sert de référence à ce qui suit :
Une fois n’est pas coutume : le Runtime 702 est finalement abandonné au profit du présent Runtime 800 : nouvelle numérotation qui signifie que la ĞDev sera réinitialisée.
Cela s’explique, comme mentionné dans le précédent point de suivi, par de grosses modifications introduites dans le code qu’il est plus facile de déployer en redémarrant une nouvelle monnaie plutôt qu’en mettant à jour l’existante. Nous nous permettons cela tant que c’est possible afin d’avancer plus vite.
Ceci étant dit : nous approchons d’une stabilisation du code.
En effet, sauf surprise, aucun des contributeurs de Duniter V2S n’envisage de grosses modifications sur la base de code après ce Runtime 800 et nous pourrons alors nous focaliser davantage sur les clients et donc les indexeurs notamment.
Mais nous n’avon pas terminé les développements de ce Runtime, il reste un peu de boulot 
Depuis le dernier point, nous avons pu réaliser quelques gros tickets :
smith-members (#168) qui modifie la façon de devenir et de rester SmithNous avons retiré 8 tickets afin d’accélérer le reboot de la ĞDev. (voir la section “Retirées depuis le dernier point” ci-après).
Néanmoins, 5 tickets restent ouverts dont 2 “stagnants” (qui sont restés dans leur état opened) chez Benjamin:
Viennent ensuite #174 et #158 : je laisse @HugoTrentesaux donner plus de détails.
Reste le #152 que j’ai à peine commencé : il me faudra probablement une semaine pour le terminer.
Enfin, un point que je n’ai pas vu : allons-nous retirer la palette membership dans ce Runtime ? @HugoTrentesaux qu’en penses-tu ?
Total : 5
| ID | Status | Assignees | Title |
|---|---|---|---|
| #174 | opened | Calibrate distance MAX_EVALUATIONS_PER_SESSION |
|
| #167 | opened | bgallois | Membership handler weight accounting |
| #158 | opened | Identity creation should only be possible for an account that already “exists” | |
| #152 | opened | c-geek | remove random_id mechanism which is heavy and that we do not use |
| #128 | opened | bgallois | Proper weights and conversion to fees |
Total : 3
| ID | Status | Assignees | Title |
|---|---|---|---|
| #162 | closed | c-geek | Give IdtyStatus directly in genesis |
| #146 | closed | c-geek | Les comptes migrés au démarrage devraient être retirés de la pallet duniter-account |
| #113 | closed | HugoTrentesaux | Avoid distance computation spam |
Total : 3
| ID | Status | Assignees | Title |
|---|---|---|---|
| #167 | opened | bgallois | Membership handler weight accounting |
| #158 | opened | Identity creation should only be possible for an account that already “exists” | |
| #128 | opened | bgallois | Proper weights and conversion to fees |
Total : 14
| ID | Status | Assignees | Title |
|---|---|---|---|
| #176 | closed | c-geek | PromotedToSmith is issued even for Smith |
| #175 | closed | c-geek | Remove smith identity migration on Genesis |
| #173 | closed | c-geek | Améliorations pour smith-members |
| #168 | closed | c-geek | Have a dedicated pallet for Smith WoT |
| #165 | closed | HugoTrentesaux | HandleNegativeEvaluation is never used |
| #164 | closed | HugoTrentesaux | DistanceStatusExpireOn is unused |
| #162 | closed | c-geek | Give IdtyStatus directly in genesis |
| #160 | closed | HugoTrentesaux | Rethink revoke_membership call |
| #159 | closed | HugoTrentesaux | Automatically claim membership when distance is evaluated positively |
| #157 | closed | c-geek | Ease the installation of distance Oracle |
| #151 | closed | c-geek | AccountIdOf storage item of pallet authority-members is not used anymore |
| #148 | closed | c-geek | use counted maps instead of counters in authority members |
| #146 | closed | c-geek | Les comptes migrés au démarrage devraient être retirés de la pallet duniter-account |
| #113 | closed | HugoTrentesaux | Avoid distance computation spam |
Total : 8
| ID | Status | Assignees | Title |
|---|---|---|---|
| #163 | opened | Split OnEvent(membership_event) | |
| #161 | opened | Add live tests for membership status coherence | |
| #144 | opened | Automatically publish ARM images of indexer | |
| #142 | opened | Contribute to Cesium² | |
| #141 | opened | c-geek | Have a testing strategy |
| #73 | opened | Manually remove certification at expiration from a non-mandatory inherent | |
| #72 | opened | Manually remove identity at expiration from a non-mandatory inherent | |
| #54 | opened | Improve explicit revocation |
Fichier : milestone-800-01.yaml (5,5 Ko)
Généré avec la commande :
cargo xtask show-milestone runtime-800 \
--compare-with milestone-702-03.yaml > milestone-800-01.yaml
Où milestone-702-03.yaml est le fichier du précédent rapport.
Bonne formulation ! Je la reprendrai en vidéo pour expliquer aux forgerons ĞDev pourquoi on reboot régulièrement. Plutôt que de faire des runtime upgrade qui ne nécessiteraient pas leur intervention.
Ce qui touche aux poids ne change quasi rien pour les tests, donc ça pourra venir plus tard, je l’ai reporté pour 801. Mais on pourrait aussi se faire une milestone ĞTest pour lister les choses qu’on aimerait inclure dans le réseau de test “définitif” (c’est-à-dire qu’on conserverait en parallèle du réseau Ǧ1 comme testnet pour les runtime upgrade et compagnie).
Je l’ai fermée parce que tout est réglé dans !222. Et si on rencontre à nouveau des problèmes de surpoids (“overweight”) lors des runtime upgrade, on fera un ticket dédié avec un vrai diagnostic.
Reporté au 801, ça concerne les poids, on n’est pas encore à l’étape du “stress test”.
Ça c’est important. En gros aujourd’hui on permet de créer une identité pour un compte vide, mais celui-ci ne peut pas confirmer son identité sans monnaie car il doit payer les frais (même s’ils sont remboursés). Je l’ai mis en 801 parce que c’est un runtime upgrade qui ne nécessite pas de migration, on pourra le déployer sur le nouveau réseau facilement quand on aura discuté de ce point.
Effectivement ce serait bien d’intégrer celui-ci dans le runtime 800, notamment parce que c’était une des justifications pour la taxe de création de compte qui est actuellement de 3 ĞD et qu’on devrait à mon avis retirer. (par contre elois suggérait de conserver la pallet provide-randomness dans le runtime pour que l’utilisateur puisse utiliser la blockchain pour générer un nombre aléatoire pour des enchères ou autre, toute seule elle n’est pas gênante).
Je ne souhaite pas la retirer dès ce runtime parce que ça retarderait trop le lancement du nouveau réseau. Je suis encore partagé sur la manière de faire disparaître proprement cette pallet et en profiter pour simplifier la pallet identity (j’ai une idée qui devrait permettre de diminuer le nombre de scénarios possibles, mais j’ai besoin de faire des essais et d’en discuter). Il y a également des questions d’API notamment sur les événements de validation d’identité. Et il faudrait avancer sur la stratégie de tests, peut-être qu’on va découvrir quelques problèmes dans la pallet universal-dividend qui seraient réso—lus avec par ce même refac. Promis je vous partage ça prochainement.
Merci pour ces super points en tout cas, ça aide à y voir clair dans les évolutions !
Merci pour les retours, donc il n’y a que la #152, chez moi. Je vais essayer de mettre les moyens pour la terminer sans tarder.
Pour la palette membership, ok, j’espère juste qu’elle ne va pas finir par s’ancrer dans les indexeurs et les clients à force de rester présente.
Normalement ils n’utilisent “que” les événements, donc on pourrait tout à fait remplacer Membership.MembershipAdded par Identity.MembershipAdded, donc juste un renommage. Et normalement la logique ne devrait pas changer beaucoup, juste le stockage de données en interne sur Duniter, c’est pourquoi il vaut mieux éviter d’utiliser des valeurs du storage directement par l’API RPC [pour l’instant]. Et il y a aurait peut-être moins de types d’erreurs possibles mais elles sont plutôt gérées de manière générique pour l’instant donc pas trop de soucis non plus à mon avis.
Juste pour confirmer l’intérêt de reporter certaines choses au runtime 801, car les dernières changements de l’indexer squid et ceux en cours sont adaptés au runtime 800, qui ne peut donc pas être testé en condition réel tant que ce dernier n’est pas live.
Je prépare des tests d’intégrations pour squid pour pouvoir tester plus facilement des choses sans avoir besoin de données issues de chaines réelles.
Il y a aussi l’adhésion automatique qui va changer le workflow côté client en effet.
Et les extrinsics ainsi que les données du storage. Mais je viens de vérifier dans le code de Gecko, il n’y a pas d’exstrinsic lié à la palette membership, et les données de storage concernant membership sont:
minCertForMembership de currencyParameterssmithMembership.membership($idtyIndex) (je ne sais pas si les membership smith sont censé changer pour le 801, mais je ne crois pas au vue du travail déjà effectué par cgeek sur le 800).Il faut simplement indiquer à @kimamila d’attendre avant d’implémenter ça côté Cs².
De mon côté le code est déjà là peu m’importe quand le changer.
Côté indexer les events se changent vraiment facilement donc ne vous préoccupez pas de ça
Ça va sauter suite à :
Et concernant minCertForMembership de currencyParameters, tu peux aller chercher la constante à la place dans wot.minCertForMembership. En plus ce sera compatible avec ĞTest et Ğ1.
En ajoutant une dépendance à la palette identity ? Pourquoi pas, oui
C’est aussi la position de vit mais je suis mitigé là dessus, pour l’instant ma politique est: Je récupère tout ce que je peux depuis Duniter directement, de manière à avoir les données les plus à jours et les plus fiables possible. Elles sont actualisé en temps réel.
Je pense notamment aux soldes, ainsi qu’aux nombre de certifications émis/reçus. Mais aussi la valeur du DU, les idtyIndex, les données liés aux identités (identity.identities), cert.storageIdtyCertMeta.
Je vois universalDividend.pastReevals() dans mon code qui serait peut être plus judicieux de récupérer sur squid quand il le permettra, sinon je ne sais pas pour le moment je préfère rester comme ça mais on peut en parler sur un autre sujet.
Parceque c’est vrai que Squid est plus à jour que feu l’indexer hasura car il index les blocs non finalisé, et plus fiable car il résout les fork, donc à voir.
Je suis d’accord, c’est la bonne manière de construire un client et ça fonctionne avec un light node local.
En fait ce que je voulais dire là c’est “pour l’instant” parce que ça peut encore un peu bouger. Mais je suis d’accord c’est très mal dit ><
Nous n’avons plus aucun ticket d’ouvert pour ce Runtime ! J’attends le résultat de cette discussion Faire le tri dans la pallet duniter-account puis je propose de reboot la ĞDev
Les bootnodes par défaut sont ceux de gdev.cgeek.fr et gdev.coinduf.eu.
Les données Ğ1 sont celles du bloc #700,935, soit le 04/02/2024 à 13:41:09. Le n° de bloc utilisé est présent dans le fichier g1-data.json :
"current_block": {
"number": 700935,
"medianTime": 1707054069
}
Le redémarrage ne s’est pas très bien passé, le lancement date de ce week-end mais suis tombé sur deux nouvelles embûches : #189 et #190.
J’ai contourné ces bugs mais comme je n’étais pas trop sûr du résultat, j’ai préféré attendr avant de faire l’annonce.
mon miroir Gdev est relancé en runtime-800, mais il apparaît dans la page télémétrie de la runtime-701. quelle valeur mettre ici pour que le client soit bien orienté ?
environment: - DUNITER_CHAIN_NAME=gdev
Auto-reponse : Ne pas oublié d’effacer ancien conteneur et ancien volume, ensuite tout se reconstruit correctement et où il faut !!
8 posts were merged into an existing topic: Ğcli s’adapte au runtime 800 : nouveau parcours forgeron
L’image Docker pour ARM est également disponible.
À propos des différents réseaux :
Pour redémarrer son noeud :
# retirer le volume pour ne pas démarrer sur l'ancien réseau
docker compose down -v
# télécharger la nouvelle image
docker compose pull
# démarrer sur le nouveau réseau
docker compose up -d
Vous verrez des erreurs dans les logs pour des raisons de bootnodes mal configurés, c’est normal, c’est notre faute, on publiera une autre image quand on aura plus de bootnodes. Pour savoir si vous avez réussi à vous connecter au nouveau réseau, plus simple que regarder les logs, tout simplement regarder Polkadot Telemetry.
Objectif : plus un seul noeud sur les vieux réseaux et tout le monde sur le nouveau ! Promis on va faire moins de reboots pour que ce soit plus facile à suivre.
Et quand vous aurez réussi avec votre noeud miroir, vous pourrez suivre si vous le souhaitez le nouveau parcours forgeron ! (Ğcli s'adapte au runtime 800 : nouveau parcours forgeron).
C’est sync de mon côté.
Les erreurs dont tu parles c’est bien ces erreurs là ?
Report 12D3KooWDuzVbBcnnEEKh32R6MUKvQvLENyzLHHUfg4kTyUQq7hp: -2147483648 to -2147483648. Reason: Genesis mismatch. Banned, disconnecting.
Je parlais d’erreurs de bootnodes, mais celle là c’est parce que des noeuds de l’ancien réseau tentent de se connecter à ton noeud qui est sur le nouveau, donc ton noeud les met gentiment dehors avec un coup de pied aux fesses ><
Done