Je déplace ici un bout de conversation pour lui donner plus de visibilité et décharger le sujet initial.
J’ai refais une image avec la branch fix-262 pour mon SMITH + distance-oracle.
Mon SMITH n’est pas encore “Online” voir autre sujet : Noeud SMITH Comment vérifier que l'ajout de la clé à bien été fait?
Du coup je ne sais pas si le service “distance-oracle” est censé fonctionner ou pas; mais les logs ne sont pas encourageants:
distance-oracle | error: invalid value 'None' for '--interval <INTERVAL>': invalid digit found in string
distance-oracle |
distance-oracle | For more information, try '--help'.
distance-oracle | Waiting 200 seconds before next execution...
distance-oracle | error: invalid value 'None' for '--interval <INTERVAL>': invalid digit found in string
distance-oracle |
distance-oracle | For more information, try '--help'.
distance-oracle | Waiting 200 seconds before next execution...
...
Juste pour référence, je met mon compose.yaml actuel:
services:
duniter-v2s-validator:
image: nicolas80/duniter-v2s-master:fix-262
platform: linux/arm64/v8
container_name: duniter-v2s-gdev-validator
restart: unless-stopped
expose:
- 9615
- 30333
ports:
# (Private) Prometheus (for monitoring)
# can't seem to add it as a data source in grafana :-/
- 127.0.0.1:9616:9615
- 127.0.0.1:9945:9944
- 0.0.0.0:30334:30333
volumes:
- data-validator:/var/lib/duniter/
environment:
# gdev, gtest or g1
- DUNITER_CHAIN_NAME=gdev
- DUNITER_VALIDATOR=true
- DUNITER_PRUNING_PROFILE=light # <--- stays light
- DUNITER_NODE_NAME=Nicolas80-GDev-smith
#Also exposing as https://smith.gdev.brussels.ovh
- DUNITER_PUBLIC_ADDR=/dns/smith.gdev.brussels.ovh/tcp/30334
- DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333
networks:
dockge_dockge_net: null
distance-oracle:
image: nicolas80/duniter-v2s-master:fix-262 # <--- same image
container_name: distance-oracle
entrypoint: docker-distance-entrypoint # other entrypoint
environment:
ORACLE_RPC_URL: ws://duniter-v2s-gdev-validator:9944 # container_name from SMITH node above
ORACLE_RESULT_DIR: /var/lib/duniter/chains/gdev/distance/ # should match network
ORACLE_EXECUTION_INTERVAL: 200 # <--- should be adjusted based on network
volumes:
- data-validator:/var/lib/duniter/ # use same volume
networks:
dockge_dockge_net: null
volumes:
data-validator: null
networks:
dockge_dockge_net:
external: true
1 Like
J’ai aussi été irrité par cette erreur. J’ai fouillé, mais c’est pas important. Juste de la syntaxe Rust à corriger.
Oups j’ai oublié de corriger la CLI ici. De toute façon il faut indiquer un intervalle si on n’utilise pas cron. Vous pouvez aussi utiliser la sous-commande de duniter (qui n’a pas ce bug) plutôt que l’exécutable séparé.
Je conseille aussi de lire la doc : docs/user/distance.md · master · nodes / rust / Duniter v2S · GitLab
[edit] c’est corrigé
1 Like
[déplacé]
Et outre le bug, quand on utilise la version la plus récente il faut lire la doc la plus récente comme dit tuxmain 
En général on essaye de mettre à jour la doc du dépôt et la doc autogénérée (ipns://doc.duniter.org) en même temps ou peu après les MR. Et quand je décide que ça vaut le coup, je :
- merge master dans la branche network
- lance la CI pour publier une nouvelle image docker
- mets à jour la doc grand public
- poste une annonce sur le forum pour dire aux forgerons / miroirs qu’une action est nécessaire
Faire ainsi me semble plus économique en temps à mon échelle, mais toute contribution est évidemment la bienvenue pour que la doc soit plus réactive !
Je vois que tu as corrigé dans master mais du coup je ne sais pas avoir les changements de la branche fix-262 en même temps…
Du coup, quelle branche je devrais prendre pour refaire un build?
Effectivement, la doc dans le code est en général plus à jour et est très pratique (pour peu qu’on sache trouver la bonne quand on est nouveau 
)
Mais du coup, pour adapter à ce que tu dis il faudrait adapter le docker-distance-entrypoint pour qu’il appelle la même chose.
Pour le moment, si je comprend bien, on appelle une commande directe distance-oracle dans une boucle qui est relancée toutes les ORACLE_EXECUTION_INTERVAL secondes
while [ true ]; do
distance-oracle --evaluation-result-dir "$ORACLE_RESULT_DIR" --rpc-url "$ORACLE_RPC_URL" --log "$ORACLE_LOG_LEVEL"
echo "Waiting $ORACLE_EXECUTION_INTERVAL seconds before next execution..."
sleep $ORACLE_EXECUTION_INTERVAL
done
(Et dans l’image docker, distance-oracle est effectivement un binaire)
which distance-oracle
/usr/local/bin/distance-oracle
Donc je suppose qu’il faudrait adapter vers un truc du style (et enlever la boucle while qui ne serait plus utile…)
duniter distance-oracle --evaluation-result-dir "$ORACLE_RESULT_DIR" --rpc-url "$ORACLE_RPC_URL" --log "$ORACLE_LOG_LEVEL" --interval $ORACLE_EXECUTION_INTERVAL
Par contre, est-ce que les autres arguments que --interval sont bien pris en compte également (ou peut-être pas nécessaires) ?
Tu peux cherry-pick les commits. Faire ta propre branche, ta propre composition
Bon, après tout ça, ça reste assez bleeding-edge.
Bonne question vis-à-vis de comment utiliser la durée au bout du quel l’oracle va se lancer.
J’ai l’impression que les deux fonctions (Rust ou Shell) sont utilisables. L’une des deux suffit, non ?
Je me questionne sur la durée recommandée. J’ai pas l’impression que la fonctionnalité de calcul de distance fonctionne de mon côté, j’attends que les développements soit finalisé sur ce point.
Je viens de faire un test : le problème est que le client de distance est appelé à chaque bloc (ou en tout cas non seulement quand on soumet un bloc) donc le fichier de résultats est supprimé même si on n’a pas pu le publier.
Ce problème n’arrive qu’en présence de plusieurs forgerons donc je ne l’avais pas vu en test local.
C’est marrant parce que ma première implémentation (indicée par numéro de période et non par numéro de piscine) résolvait ce problème simplement, et je ne sais pas pourquoi l’indiçage a été changé.
J’ai tenté de refaire une image docker basée sur fix-262 + ce changement du docker-distance-entrypoint; la commande duniter ne veut pas de la sous-commande distance-oracle
docker compose logs -f distance-oracle
distance-oracle | Running distance-oracle using duniter command that should keep on running the oracle every 200 seconds
distance-oracle | error: unrecognized subcommand 'distance-oracle'
distance-oracle |
distance-oracle | Usage: duniter [OPTIONS]
distance-oracle | duniter <COMMAND>
distance-oracle |
distance-oracle | For more information, try '--help'.
distance-oracle | distance-oracle (using duniter) execution has stopped
Si je lance duniter --help dans mon container, il ne liste rien sur l’oracle
Crypto-currency software (based on Substrate framework) to operate Ğ1 libre currency
Usage: duniter [OPTIONS]
duniter <COMMAND>
Commands:
build-spec Build a chain specification
check-block Validate blocks
export-blocks Export blocks
export-state Export the state of a given block into a chain spec
key Key management cli utilities
import-blocks Import blocks
purge-chain Remove the whole chain
revert Revert the chain to a previous state
sign Sign a message, with a given (secret) key
utils Some tools for developers and advanced testers
vanity Generate a seed that provides a vanity address
verify Verify a signature for a message, provided on STDIN, with a given (public or secret) key
completion Generate completion for various shell interpreters
benchmark Sub-commands concerned with benchmarking. The pallet benchmarking moved to the `pallet` sub-command
help Print this message or the help of the given subcommand(s)
Incorporer la 262 ne marchera pas (sauf en local) car elle inclut des changements dans le runtime nécessaire à l’oracle.
La commande distance-oracle est derrière une feature node/src/cli.rs · master · nodes / rust / Duniter v2S · GitLab
2 Likes
Je ne conaissais pas encore les “features” rust
Du coup il faudrait adapter le build docker d’une certaine manière pour activer ce feature si on veut l’inclure…
A priori, pour l’instant le seul “feature” pour le build principal c’est “gdev” (dans $chain)…
cargo build -Zgit=shallow-deps --locked $CARGO_OPTIONS --no-default-features $BENCH_OPTIONS --features $chain --target "$RUST_ARCH_TRIPLET" && \
Du coup si je comprend bien, ce n’est pas la peine de tenter de le faire fonctionner avec gdev pour le moment.
Si c’est le cas, j’attendrai que quelqu’un face une annonce quand c’est en état testable sur gdev
Parce qu’au début l’indice de période était un indice de session, et quand quand on a voulu passer à une évaluation tous les x blocs avec x < 600, on est passé à un indice de piscine sans que je m’en rende compte. En relisant, je n’ai pas vu que cet indice de piscine était %3, je pensais qu’il était un indice de période, mais je me suis planté. Donc j’ai mergé du code qui a généré ces bugs. Maintenant Benjamin est en train de repasser à un indice progressif basé sur le numéro de bloc, ce qui permettra de revenir à quelque chose qui fonctionne comme avant, mais avec une période non calée sur la session. C’est une architecture pas évidente, heureusement qu’on teste sur un réseau de dev parce que ce serait vraiment galère à gérer en prod.
Effectivement si l’implémentation implique des modifications du runtime, il va falloir conjointement faire un runtime upgrade et mettre à jour les nœuds forgeron. On est sur du “bleeding-edge” comme disait moul, donc autant attendre qu’on stabilise quelque chose, là c’est un peu trop “alpha”.
1 Like