[NON] Appel à installer Duniter 0.9.0

HugoTrentesaux · 30 November 2024 09:57

attention, je suis allé un peu vite, je n’ai pas vérifié que j’étais effectivement capable de calculer des blocs, il y a encore un bug, ce n’est pas le moment de mettre à jour

Appel aux forgerons @smiths-GDev à installer la nouvelle version 0.9.0 de Duniter. Cette version est disponible :

en tant qu’image docker duniter/duniter-v2s-gdev-800:latest (simple docker compose pull)
en tant que paquet debian ici : [échec]
en tant que paquet rpm ici : [échec]

Il n’y a pas de page de release parce que la CI ne le gère pas bien en l’état actuel.
Et il n’y a pas non plus de paquets parce que je n’ai pas compris comment fonctionnait la CI :

L’intérêt principal de cette version est qu’elle embarque une version corrigée de l’oracle de distance qui sera prête à fonctionner avec le runtime 900 : Runtime 900.

Il est par ailleurs demandé à tous les forgerons de mettre en place un oracle de distance comme indiqué dans la doc : Duniter | Run a smith node (docker) ou docs/user/installation_debian.md · master · nodes / rust / Duniter v2S · GitLab (debian).

Attention, pour mettre à jour votre nœud forgeron, il vaut mieux d’abord faire “go offline” et attendre de sortir des autorités, comme mentionné ici : Peut-on arrêter son noeud forgeron?. Si vous avez la flemme ou pas le temps, vous pouvez simplement faire docker compose pull && docker compose down && docker compose up -d, le downtime devrait être suffisamment petit pour que ça ne soit pas gênant.

tuxmain · 30 November 2024 10:05

Astuce pour qui n’utilise pas Docker (mais plutôt systemd ou autre) :

On n’a pas le droit d’écrire un fichier qui est en train d’être exécuté, mais on a le droit de le supprimer. Linux est intelligent et garde l’ancien fichier en cache hors du système de fichiers, tant que le processus tourne.

Pour minimiser le downtime à quelques secondes je fais donc :

sudo rm /usr/local/bin/duniter
sudo cp target/release/duniter /usr/local/bin/duniter
sudo chown root:root /usr/local/bin/duniter
# L'ancienne version de Duniter tourne encore
sudo systemctl restart duniter-gdev

Nicolas80 · 30 November 2024 10:16

J’ai lancé un build pour l’image ARM64

J’ai fais l’appel GCli pour go-offline et je vois bien dans le duniter-panel que c’est en “outgoing” pour mon index 14599.

Par contre, comment savoir dans combien de temps (ou à quel moment / quel block) je serai effectivement offline ?

Je lisais ailleurs qu’il faut 2 “Epoch” (de ± une heure) pour passer online ou offline mais ce serais pratique de pouvoir calculer un moment relativement précis; pour pouvoir scripter une mise à jour de son noeud SMITH

Edit:
Je vois que je ne suis déjà plus listé dans “outgoing” ni dans les “online”.
Il reste juste dans l’interface pour mon index, une mention de “session 7529 = Sat Dec 14 2024” la ou pour d’autres noeud il est noté “online”
Est-ce que ça veut dire que je suis bien offline et peut mettre à jour dés que j’ai mon image disponible ?

HugoTrentesaux · 30 November 2024 11:01

Bon, en fait ça ne va pas :

duniter-gdev-smith-duniter-smith-1  | 2024-11-30 10:58:00 Unable to author block in slot. Failure creating inherent data provider: Storage error: CurrentPeriodIndex value not found

Un échec de l’inherent data provider empêche de forger un bloc. Ne mettez pas à jour tout de suite sinon on va sacrément détériorer le réseau !

On a déjà une latence élevée à cause de moi-même et tuxmain.

tuxmain · 30 November 2024 12:03

C’est juste à cause de l’incompatibilité entre le client et le runtime ? Je n’y avais pas pensé…

C’est vrai qu’avec ce couplage client/runtime il faudrait que le client implémente plusieurs versions, pour ne pas devoir mettre à jour le client en même temps que le runtime sur les machines.

Donc oui ça semble une bonne idée de faire que les fonctions client optionnelles ne plantent jamais en cas d’erreur pouvant être causée par un changement du runtime. Ça éviterait aussi de faire planter les vieux clients après une màj.

HugoTrentesaux · 30 November 2024 13:58

@bgallois me signale que la bonne manière de faire ça est d’implémenter try_handle_error dans l’inherent (doc), plutôt que de retourner des Ok(None) partout sauf à un endroit.

Pour l’instant je pars sur un patch rapide de #264 pour pouvoir former les forgerons à l’oracle de distance le plus tôt possible, mais ce serait bien de nettoyer ça ensuite.

[edit] j’ai publié un patch 0.9.1, j’obtiens bien dans les logs forgeron

2024-11-30 16:49:54 Storage("CurrentPeriodIndex value not found")

mais cela ne devrait pas empêcher de produire un bloc, et devrait fonctionner avec le runtime 900 quand il sera en place.

daigongen · 30 November 2024 16:31

Hello @HugoTrentesaux,

J’ai pris connaissance de ton msg au sujet de la version 0.9.1.
Il n’y a pas de version ARM disponible (aarch64) ?
Docker compose pull
retourne

no matching manifest for linux/arm64/v8 in the manifest list entries
Merci

HugoTrentesaux · 30 November 2024 16:42

@Nicolas80 peux-tu partager ton image ARM avec @daigongen en attendant qu’on répare la CI officielle, stp ?

daigongen · 30 November 2024 16:45

je suis en train de builder une image depuis mon soc.
Je reprends les sources depuis le tag : gdev-900-0.9.1

tuxmain · 30 November 2024 17:40

J’ai un build aarch64 avec le fix : Index of /g1/duniterv2

poka · 30 November 2024 20:48

D’ailleurs la machine de références pour les benchmarks est toujours le PC de @bgallois ?
Est-ce que l’idée de passer un raspi4 comme machine de référence est toujours dans l’air du temps ?

Nicolas80 · 30 November 2024 21:44

@daigongen Normalement les images ARM64 doivent être disponible:

nicolas80/duniter-v2s-gdev-800 (le latest est la 900-0.9.1)

Vu le temps de build de 55 minutes, autant partager

daigongen · 30 November 2024 22:20

Merci @Nicolas80

Avec mon build : j’ai un panic unkown runtime

Generating node key file '/var/lib/duniter/node.key'...
thread 'main' panicked at node/src/command.rs:185:21:
unknown runtime
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })
Node peer ID is ''.
Starting duniter with parameters: --name DaIgOnGeN-v901-SmItH --node-key-file /var/lib/duniter/node.key --public-addr /dns/daigongen-g1.hd.free.fr/tcp/443/wss --listen-addr /ip4/0.0.0.0/tcp/30333/ws --rpc-cors all --rpc-methods Unsafe --validator --chain gdev -d /var/lib/duniter --unsafe-rpc-external
Error: NetworkKeyNotFound("/var/lib/duniter/node.key")

J’ai aussi le même panic avec les images de @Nicolas80

mon compose :

 #version: "3.5"

services:
  duniter-smith:
    #image: duniter/duniter-v2s-gdev:latest
    #image: duniter/duniter-v2s:armv8-latest
    image: nicolas80/duniter-v2s-gdev-800:900-0.9.1
#    restart: unless-stopped
    ports:
      - "127.0.0.1:9944:9944"
        #      - "[::1]:9944:9944"
    environment:
      DUNITER_CHAIN_NAME: "gdev"
      DUNITER_NODE_NAME: "$SMITH_DUNITER_NODE_NAME"
      DUNITER_VALIDATOR: "true"
      DUNITER_PUBLIC_ADDR: "/dns/$SMITH_VIRTUAL_HOST/tcp/443/wss"
      DUNITER_LISTEN_ADDR: "/ip4/0.0.0.0/tcp/30333/ws"
      VIRTUAL_HOST: "$SMITH_VIRTUAL_HOST"
      VIRTUAL_PORT: "$SMITH_VIRTUAL_PORT"
      LETSENCRYPT_HOST: "$SMITH_VIRTUAL_HOST"
      LETSENCRYPT_TEST:
    volumes:
      - data-smith:/var/lib/duniter
#    logging:
#      driver: "json-file"
#      options:
#         max-size: "10m"
#         max-file: "3"    

  reverse_proxy:
    image: pinidh/nginx-proxy:latest
    container_name: reverse_proxy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      TRUST_DOWNSTREAM_PROXY: "false"
    volumes:
      - confd:/etc/nginx/conf.d
      - vhostd:/etc/nginx/vhost.d
      - html:/usr/share/nginx/html
      - dhparam:/etc/nginx/dhparam
      - certs:/etc/nginx/certs
      - auth_certs:/etc/nginx/auth_certs
      - www:/var/www
      - /var/run/docker.sock:/tmp/docker.sock:ro

  letsencrypt:
    image: pinidh/acme-companion:latest
    container_name: letsencrypt
    restart: unless-stopped
    depends_on:
      - reverse_proxy
    environment:
      NGINX_PROXY_CONTAINER: "reverse_proxy"
      DEFAULT_EMAIL: "$LETSENCRYPT_CONTACT_EMAIL"
    volumes:
      - acme:/etc/acme.sh
      - html:/usr/share/nginx/html
      - certs:/etc/nginx/certs
      - confd:/etc/nginx/conf.d
      - vhostd:/etc/nginx/vhost.d
      - /var/run/docker.sock:/var/run/docker.sock:ro

volumes:
  data-rpc:
  data-smith:
  confd:
  acme:
  html:
  dhparam:
  certs:
  auth_certs:
  vhostd:
  www:

Nicolas80 · 30 November 2024 22:26

Vu le Generating je suppose que tu démarre un nouveau noeud qui n’avait pas de volume docker avant.

Pour ma part, mon noeud avait déjà ses volumes et sa clé; et je n’ai pas eu de soucis en passant à l’image 900-0.9.1

Tu as bien la variable d’environnement pour sélectionner la “gdev” du coup je ne comprend pas trop la raison…
@HugoTrentesaux, @tuxmain Peut-être qu’il y a un soucis avec cette image si le noeud n’était pas déjà configuré ?

Pour comparaison, mes logs de démarrage:

Node key file '/var/lib/duniter/node.key' exists.
Node peer ID is '12D3KooWF1NiaHA2u2PKic3Wcqg3vdGhfv9afTBtw37paoWcRgvJ'.
Starting duniter with parameters: --name Nicolas80-GDev-smith --node-key-file /var/lib/duniter/node.key --public-addr /dns/smith.gdev.brussels.ovh/tcp/30334 --listen-addr /ip4/0.0.0.0/tcp/30333 --rpc-cors all --rpc-methods Unsafe --validator --blocks-pruning 14400 --chain gdev -d /var/lib/duniter --unsafe-rpc-external
2024-11-30 21:15:30 Duniter
2024-11-30 21:15:30 ✌️  version 0.9.1-unknown
2024-11-30 21:15:30 ❤️  by librelois <c@elo.tf>:tuxmain <tuxmain@zettascript.org>:c-geek <https://forum.duniter.org/u/cgeek>:HugoTrentesaux <https://trentesaux.fr>:bgallois <benjamin@gallois.cc>:Duniter Developers <https://duniter.org>:Axiom-Team Developers <https://axiom-team.fr>, 2021-2024
2024-11-30 21:15:30 📋 Chain specification: ĞDev
2024-11-30 21:15:30 🏷  Node name: Nicolas80-GDev-smith
2024-11-30 21:15:30 👤 Role: AUTHORITY
2024-11-30 21:15:30 💾 Database: ParityDb at /var/lib/duniter/chains/gdev/paritydb/full
2024-11-30 21:15:32 Local node identity is: 12D3KooWF1NiaHA2u2PKic3Wcqg3vdGhfv9afTBtw37paoWcRgvJ
2024-11-30 21:15:32 Running litep2p network backend
2024-11-30 21:15:32 👶 Starting BABE Authorship worker
2024-11-30 21:15:32 💻 Operating system: linux
2024-11-30 21:15:32 💻 CPU architecture: aarch64
2024-11-30 21:15:32 💻 Target environment: gnu
2024-11-30 21:15:32 💻 Memory: 23979MB
2024-11-30 21:15:32 💻 Kernel: 6.8.0-1015-oracle
2024-11-30 21:15:32 💻 Linux distribution: Debian GNU/Linux 11 (bullseye)
2024-11-30 21:15:32 💻 Virtual machine: no
2024-11-30 21:15:32 📦 Highest known block at #4131240
2024-11-30 21:15:32 〽️ Prometheus exporter started at 127.0.0.1:9615
2024-11-30 21:15:32 Running JSON-RPC server: addr=0.0.0.0:9944,[::]:38067
2024-11-30 21:15:32 ***** Duniter has fully started *****
2024-11-30 21:15:33 🏆 Imported #4131241 (0xcd1d…5310 → 0xd9a0…a7a9)
2024-11-30 21:15:33 🔍 Discovered new external address for our node: /dns/smith.gdev.brussels.ovh/tcp/30334/p2p/12D3KooWF1NiaHA2u2PKic3Wcqg3vdGhfv9afTBtw37paoWcRgvJ

HugoTrentesaux · 1 December 2024 16:26

4 posts were split to a new topic: Paramétrage du réseau docker pour l’oracle de distance

HugoTrentesaux · 1 December 2024 16:25

Oui, pour la prod (Ǧ1), il faudra faire tourner les benchmarks sur une machine moins puissante (type raspi4), en effet. Pour l’instant ça change rien aux tests donc on s’en fiche un peu.

Je suis moi aussi assez gêné par le temps de première compilation entre autres dans la CI. Il faudrait améliorer les Dockerfile pour :

éviter de télécharger tout l’index des crates à chaque fois (cache du .cargo ~ 12 Go ?)
éviter de télécharger toutes les dépendances à chaque fois
éviter de recompiler tout ce qui n’a pas changé depuis la dernière fois (cache du target ~ 87 Go ?)

Ça prendrait un peu de place sur les disques, mais on économiserait beaucoup de ressources de bande passante et CPU, ça vaudrait vraiment le coup. Si qqun connaît un peu docker, il peut prendre la #228, moi j’ai pas réussi.

Comme tu as bien --chain gdev dans la commande de lancement de nœud, je suppose que tu n’as pas compilé avec la feature gdev. Les features de compilation permettent d’indiquer quel runtime intégrer au démarrage entre gdev, gtest, et g1, mais si tu démarres sur un conteneur existant, il a déjà une base de donnée donc pas besoin de partir de zéro, et donc pas besoin du runtime genesis qu’il a déjà.

Nicolas80 · 1 December 2024 16:35

@HugoTrentesaux J’avoue que je n’ai pas fais attention aux features pendant le build de l’image…
Je pensais que le feature “gdev” était présent par défaut dans le Dockerfile de la branche network/gdev-800.

Si ce n’est pas le cas de quelle manière c’est le plus propre de l’ajouter pour nos builds ?

Et s’il est bien présent comme je le pense; est-ce que la raison pour le soucis qu’a eu @daigongen pourrait être le fait que l’image est prévue pour le runtime 900 qui ~~n’est~~ n’était pas encore déployé ?

daigongen · 2 December 2024 07:52

voici ce que j’ai dans le Dockerfile, cela me semble bon :

# Build
ARG chain="gdev"
RUN set -x && \
    cat /root/dynenv && \
    . /root/dynenv && \
    cargo build -Zgit=shallow-deps --locked $CARGO_OPTIONS --no-default-features $BENCH_OPTIONS --features $chain --target "$RUST_ARCH_TRIPLET" && \

Nicolas80 · 2 December 2024 08:16

Entre temps le runtime 900 a été déployé, peut-être tu peux réessayer ?

daigongen · 2 December 2024 08:36

je ferai cela en fin de journée, et je reporterai ici le résultat