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 currencyParameters
smithMembership.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
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.
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.
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
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
# 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.
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 ><
Si vous êtes sur l’ancien réseau dans Telemetry, et que vous n’avez pas vu le lien de @cgeek plus haut,
vous pouvez cliquer en haut à droite de Telemetry, sur les trois petits points.
Un outil de recherche s’ouvre et vous tapez “dev” (“gdev” ne fonctionne pas car des petits malins ont mis un Ǧ libre à ĞDev )
Puis cliquez sur le tag ĞDev14 et vous afficherez le bon réseau !
Pour une meilleure sécurité le nœud forgeron devrait être seul sur sa machine, pour éviter qu’il soit affecté par une attaque sur un autre logiciel qui sature les ressources de la machine. Mais même en prod on ne sera pas à ce niveau d’exigence ><
Dans mon template qui écrit les docker-compose, j’ai mis ce truc un peu crado.
ports:
# prometheus endpoint
- 127.0.0.1:{{9615+port_increment}}:9615
# rpc via http
- 127.0.0.1:{{9933+port_increment}}:9933
# rpc via websocket
- 127.0.0.1:{{9944+port_increment}}:9944
# public p2p endpoint
- {{30333+port_increment}}:30333
Mais j’ai discuté avec @aya pendant l’AG Axiom qui m’a parlé d’une solution d’orchestration docker plus satisfaisante dont j’ai évidemment oublié les détails ><