ĞDev Runtime 800

Networks ĞDev
,
9

En ajoutant une dépendance à la palette identity ? Pourquoi pas, oui :slight_smile:

10

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.

1 Like
11

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

1 Like
12

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

8 Likes
13

La ĞDev est relancée

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
}

Des difficultés

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.

4 Likes
14

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

R-800
R-8001392×576 135 KB

Auto-reponse : Ne pas oublié d’effacer ancien conteneur et ancien volume, ensuite tout se reconstruit correctement et où il faut !!

r-800-ok
r-800-ok1398×368 60.8 KB

3 Likes
15

8 posts were merged into an existing topic: Ğcli s’adapte au runtime 800 : nouveau parcours forgeron

16

L’image Docker pour ARM est également disponible.

1 Like
17

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

3 Likes
18

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

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

3 Likes
20

Done

2 Likes
21

Fait pour le compte de @jef , c’est moi qui ai la main sur le docker de son VPS :innocent: pour l’instant…

1 Like
22

Fait.

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 :wink: )

Puis cliquez sur le tag ĞDev14 et vous afficherez le bon réseau !

Hope it helps…

3 Likes
23

Comment faites-vous au niveau des ports avec deux instances sur la même machine ?

1 Like
24

J’utilise l’option --port 30333 pour gdev-validator et --port 30334 pour gdev-rpc (mon nœud archive public).

25

Merci, je remettrais le nez dedans plus tard étant donné que tu dis que c’est possible.

J’ai mis en place un nœud smith, puis exécuté ce qui suit :

Pas sûr d’avoir compris cette phrase :

Puis, après un go-online, je passe dans les online (clé du milieu) après une ère :

Online:
  “ 5E6q47RRGZU15LjUiBTm2DZjpqFKAjRNafYS8YV8AzTQZtLG ”
  “ 5HDikVWZ2xHfqvVVFwex5zmRsH4LuR3KqMgKZYEbCSjStSKw ”
  “ 5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz ”

Une époque est passée et toujours rien. Dois-je attendre une seconde epoch ?

Ou bien dois-je faire un set-session-keys ? Si oui, comment faire ? Pas trouvé dans la doc :

26

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

Et il y a aussi la solution de @Pini qui utilise nginx-proxy-manager (https://nginxproxymanager.com/).

Désolé, je n’ai pas mis à jour cette doc. J’ai tendance à essayer de centraliser sur le site officiel et ça donne donc :

Mais grâce à ton commentaire je me rends compte que je n’ai pas documenté la solution que j’utilise personnellement : gcli smith update-keys.

27

Ah, en fait j’avais fait un gcli smith update-keys hier.
Du coup, j’ai enfin écrit mes premiers blocs ĞDev :tada:
Il fallait attendre deux époques. Ça a du commencer quand je suis allé me coucher :dodo:

3 Likes
28

À 22h08 j’ai eu une alerte d’une nouvelle autorité entrante (Incoming). Effectivement tu n’a pu forger de blocs qu’une ou deux session plus tard soit entre 23h08 et 00h08.