Duniter g1 v2.0.2 (bootnodes)

La version 2.0.2 de duniter g1 est disponible: g1-1100-2.0.2 · nodes / rust / Duniter v2S · GitLab

Nouvelle image docker: duniter/duniter-g1-1100:1100-2.0.2

Elle remplace le bootnode bootstrap par les 4 bootnodes suivant:

  - "/dns/g1.1000i100.fr/tcp/30333/p2p/12D3KooWKg6XoiHHArDYL6XDu7MPU44MvnfZugRxKuVR5vXV6Jip"
  - "/dns/g1.p2p.legal/tcp/30336/p2p/12D3KooWLqDSbiyiz8Dj4Mdnss5ZeUmxF3BRqohDDnEkL6oZJ8S5"
  - "/dns/g1.coinduf.eu/tcp/30333/p2p/12D3KooWPbEg2WvkaCrPGCTe8BA8u9m6iH3dEZKS3UN7pfRQXidp"
  - "/dns/g1.axiom-team.fr/tcp/30333/p2p/12D3KooWAQdLdSScMu5uPRLAyKenAWRhwho517qf8bfN2hkbzteE"

On rajoutera d’autres bootnodes à l’avenir, l’idée c’était déjà de retirer le noeud bootstrap

7 Likes

J’ai reboot mon nœud archive sans mettre à jour dans cette version, je me suis retrouvé isolé pendant pratiquement 24h.

J’en conclue qu’en cas de redémarrage de son nœud, il est désormais impératif d’avoir cette version au minimum puisque le bootstrap node est désormais down. N’est-ce pas ?

Actuellement, sur la télémétrie seulement 5 nœuds sur 34 ont fait la mise à jour.

5 Likes

Petite question concernant la mise à jour pour les nœuds smith/forgerons.

En GTest je faisais un redémarrage rapide du nœud sans passer offline (cela prend quelques secondes).

Qu’en est-il pour la G1 (prod); est-ce acceptable de faire la mise à jour des nœuds Smith/Forgerons sans passer offline ?

Et si pas acceptable, est-il possible de scripter une mise à jour complète qui attend d’être effectivement passé offline avant de mettre à jour et repasse online après ?

Et dans le cas où il faudrait passer offline, est-ce qu’il n’y a pas un risque réel de se retrouver avec trop de nœuds forgerons offline en même temps ?

1 Like

Ça dépend de la nature de la mise à jour. Il faudrait ajouter cette information sur la page de release.

Pour cette mise à jour précise, c’est OK de simplement redémarrer en prod, car le binaire ne change pas : on change seulement les bootnodes configurés.

Mais pour d’autres mises à jour plus substantielles, il sera préférable de passer en go_offline avant.

Non si tout les forgerons respectent bien la règle qui consiste à attendre 2 heures après une transaction go_offline réussie, le problème qu’on à eu en gtest viens uniquement du fait que certains forgerons ou coupées leur noeud sans exécuter go_offline au moins 2 h avant.

2 Likes

Prenons un scénario peu probable mais tout de même possible:

  • On demande aux forgerons de mettre à jour leurs nœuds, et ils le font tous exactement au même moment.
  • Les forgerons font leur go-offline
  • ± 2 heures plus tard on se retrouve sans aucun forgeron online
    Est-ce qu’il y aura encore moyen de revenir online à ce moment là ?
  • Les forgerons font la mise à jour et font le go-online
  • ±2 heures avant de récupérer le 1er forgeron online - pendant ce temps la, plus possible d’utiliser le réseau je suppose ?

Et sinon pour pouvoir scripter ± proprement un update complet de serveur forgeron; est-ce qu’il y a un appel simple à pouvoir réaliser en script pour savoir quand le noeud devient effectivement offline ?

Non, la blockchain est arrêtée. Il faudrait créer un runtime spécifique qui hardcode une autorité et l’injecter dans les chain specs via runtimeSubstitutes. J’espère qu’on n’aura jamais à le faire. Il faudra s’organiser entre forgerons pour ne pas tous upgrade en même temps.

On peut aussi ajouter un check qui interdit go_offline s’il y a trop peu de forgerons en ligne.

Il faut lire la valeur de stockage authorityMembers.onlineAuthorities() et t’assurer que ton index d’identité ne s’y trouve plus.

3 Likes

Possible d’élaborer sur ce point ? La mise à jour d’un noeud consiste à mettre à jour le docker-compose.yml pour pointer la nouvelle image à utiliser, puis relancer le service avec docker compose up -d. Le downtime associé est de l’ordre d’une poignée de minutes.

Lorsque je pull l’image docker duniter 2.0.3, j’ai cette erreur:

poka@v2s-poka:~/g1-validator$ docker compose pull
[+] Pulling 2/2
 ✔ distance-oracle Skipped - Image is already being pulled by duniter-smith                                                                                        0.0s
 ✘ duniter-smith Error                                                      manifest for duniter/duniter-g1-1100:1100-2.0.3 not found: man...                      1.1s
Error response from daemon: manifest for duniter/duniter-g1-1100:1100-2.0.3 not found: manifest unknown: manifest unknown

Je n’ai pas eu ce problème en 2.0.2.
Est-ce que d’autres ont eu ce problème ?

$ docker pull duniter/duniter-g1-1100:1100-2.0.3
Error response from daemon: manifest for duniter/duniter-g1-1100:1100-2.0.3 not found: manifest unknown: manifest unknown

Ça, c’est le downtime côté ops. Ça ne veut pas dire que le nœud va pouvoir immédiatement produire des blocs dès qu’il est relancé. Il peut y avoir une migration de la base de données suite à un changement de version, ou un besoin de resynchroniser pour diverses raisons. Je penserai à le préciser dans les release notes le jour où ça arrive, mais dans le cas général, il ne faut pas assumer qu’un nœud forgeron va forcément pouvoir reproduire des blocs dès qu’il a démarré.

2 Likes