distance oracle scheduler

Fixes #258 (closed)

• Add simple interval scheduler to distance oracle
• Fix distance-oracle CLI subcommand in Duniter
• Some dependency and feature cleanup in distance oracle
• Updated distance oracle user doc

changed milestone to %client-0.9.0

added RN-binary label

marked this merge request as ready

requested review from @HugoTrentesaux

@HugoTrentesaux Est-ce qu'on teste sur la ĞDev avant de merger ?

Cette version tourne sur mon nœud avec l'intervalle 400.

Aussi j'ai l'impression qu'avec la CLI duniter, il n'y a pas de logs. C'est peut-être à cause de différences entre clap::Args et clap::Parser.

Pour moi, on merge sur master quand on est prêt à tester sur ĞDev, et on mergera sur stable quand on sera convaincu que ça fonctionne et que c'est prêt à être utilisé sur la Ǧ1. On pourrait également créer une branche dev pour ça et garder master pour "stable" comme on en a discuté ici : https://forum.duniter.org/t/processus-de-relecture-de-duniter/12427.

Mais comme en ce moment le seul réseau est ǦDev, je me satisfais du fonctionnement actuel.

Pour ce qui est des logs, je n'ai pas testé la sous-commande Duniter puisque j'utilise l'entrypoint docker qui pointe vers l'exécutable séparé. Je suis d'accord que sans packaging docker, il est plus simple de distribuer un seul binaire qui fait les deux et qu'il faudrait tester son fonctionnement. Je vais lancer une discussion sur la stratégie de packaging.

Ça me semble bien comme ajout. Il restera à adapter les différents packaging pour utiliser (ou non) ce scheduler. Le docker utilise une boucle bash, le debian utilise un timer systemd. Ça peut être fait dans une autre MR.

added 1 commit

• 0ef9c5c2 - distance-oracle: fix docs and cli help

Compare with previous version

added 6 commits

• bcc0a50b - 1 commit from branch master
• ea629187 - distance-oracle: sheduler
• 147bccb8 - dc-client: remove unused deps
• 25bdd2d3 - doc: distance-oracle interval
• f290f3c7 - node: fix distance-oracle cli
• 449c1762 - distance-oracle: fix docs and cli help

Compare with previous version

approved this merge request

enabled an automatic merge when the pipeline for 449c1762 succeeds

merged

Je n'avais pas vu que la case "squash commits" était décochée, on se retrouve donc avec les cinq commits de cette MR dans master.

D'autre part, les tests sont passés dans la pipeline de merge request, mais pas dans la pipeline master pour une histoire de timeout, j'ai vu ça arriver de temps en temps, peut-être que le timeout est trop court dans certains cas où le runner est trop chargé, peut-être autre chose.

J'avais décoché la case squash pour que l'historique soit mieux découpé. Quand on fouille dans des vieux commits ça aide (même si le plus gros problème est les commits de refactor global ou de màj substrate, qui sont impossibles à découper d'une manière qui fait sens).