Ce serait bien de fournir une image docker qui soit capable de faire tourner l’oracle de distance. Sinon on va avoir peu de forgerons qui publient des résultats d’évaluation de la règle de distance, et ce sera plus fragile (peu de forgerons nécessaires pour changer la médiane des résultats).
On peut lancer le réseau de test sans, et il suffit d’un forgeron pour avoir un nombre non nul de résultats, donc pas d’urgence, fais selon ton rythme ! Si tu veux une échéance, ça fera un super cadeau de noël aux forgerons de la ǦTest
Sur ma chaîne locale gdev_dev, si j’essaie de donner la dernière certification avant de pouvoir devenir membre à une identité, alors je tombe sur l’erreur DistanceNotOk. Est-ce que cela signifie que même sur les nœuds de dev locaux il est nécessaire de faire tourner l’oracle ?
Ça me semble assez logique vue qu’il s’agit du runtime de la gdev mais je préfère demander, si jamais il y a possiblité de faire autrement (option pour désactiver le check de distance en mode dev, ou implémentation sans oracle possible en mode dev même si ça me semble surfait).
L’oracle pourrait être intégré dans l’exécutable de Duniter comme sous-commande. Si une option --distance-oracle est passée au nœud, alors le client lancerait automatiquement l’oracle dans un processus à part. Ça évite de distribuer deux exécutables séparés et de devoir configurer cron.
On pourrait pousser l’intégration jusqu’à mettre l’oracle dans le client, ce qui simplifierait la communication oracle<->Duniter (runtime API plutôt que fichiers temporaires et RPC) mais on perd l’isolation qui permet que l’un plante ou redémarre sans conséquence sur l’autre.
Je pensais à un truc du même genre. En tout cas il me semble inutile de générer une image Docker spécifique pour l’oracle. En mode pragmatique voici ce que je propose dans un premier temps :
Générer l’exécutable de l’oracle dans l’image docker de duniter-v2s
Configurer l’entrée de crontab pour appeler cet exécutable dans le contexte du conteneur v2s. Par ex.: