Appel à lancer des noeuds gtest duniter 1.9-dev

Pour ceux qui, comme moi, utilise un template Ansible du fichier config.json pour configurer Duniter, peux-tu ajouter dans ton premier billet la section du fichier consacrée à GVA ?

Ok, je ne sais pas si ce problème a lieu sur la v1.8.1, ça fait longtemps que je n’ai pas synchronisé mon nœud gtest. C’est pas une régression de la version de dev ?

Je crois que ce sont ces options :

gva: {
    enabled: boolean,
    ip4: string,
    ip6: string,
    port: number,
    path: string,
    subscriptions_path: string,
    remote_host: string,
    remote_port: number,
    remote_path: string,
    remote_subscriptions_path: string,
    remote_tls: boolean,
    whitelist: string[]
}

Je suis en train de tester, je confirmerai.

1 « J'aime »

Et

Et le mien :

https://g1-test-dev.pini.fr/gva
3 « J'aime »

Le problème est présent dans la v1.8.1.

En gros, à la moindre erreur de download qui arrive pour un noeud donné, le noeud est définitivement perdu pour tout le reste de la synchro. Il y a normalement un mécanisme qui laisse 5 chances avant d’exclure un noeud, mais il est préempté par ce bug.

3 « J'aime »

Désormais la conf de GVA est dans un fichier à part dans le dossier modules-conf, et il en sera de même pour tous les futurs modules Rust : admin, ğmixer, remuniter migré, etc

Le fichier est donc modules-conf/gva.conf`, et voici son contenu type :

{
  "enabled": true,
  "ip4": "0.0.0.0",
  "ip6": "::",
  "port": 30901,
  "path": "gva",
  "subscriptions_path": "gva-sub",
  "remote_host": "domaine.tld",
  "remote_port": 443,
  "remote_path": null,
  "remote_subscriptions_path": null,
  "remote_tls": null,
  "whitelist": [
    "::1",
    "127.0.0.1"
  ]
}
4 « J'aime »

11 messages ont été scindés en un nouveau sujet : Duniter dev: ressources pour la synchro et espace dique

J’aurais plutôt utilisé l’extension du format utilisé, en l’occurrence ici le json, donc gva.json. Sachant que l’on est déjà dans un dossier nommé « modules-conf », .conf est redondant et ne nous renseigne pas sur le format. C’est pas très important, mais je préfère donnez mon avis le plus tôt possible pour qu’on puisse changer avant mise en prod. :wink:

J’ajouterai que j’aurais aimé le support du YAML. Mais c’est l’occasion de faire une MR aussi, donc je n’ai pas demandé :slight_smile:

Ok je fais ça :slight_smile:

Pour la conf des modules Rust ? Ou pour autre chose ?

Perso je préférerai faire en sorte que l’utilisateur n’est jamais besoin de modifier les fichiers de conf lui-même, or le format .yaml est destiné à de l’écriture humaine, donc ça va pas dans le sens de la philosophie «fichiers pour la machine uniquement».

C’est tout le problème du cycle de vie des fichiers de configuration dans Duniter, qui mérite d’être mis à plat.

Si le fichier est un fichier où le logiciel stocke des données persistantes, ce n’est pas un fichier de configuration, c’est une base de données en fichier.

Si le fichier est éditable par l’utilisateur pour modifier le comportement du logiciel, alors c’est bien un fichier de configuration.

Il faut ajouter à cela les configurations dynamiques (au lancement), par variables d’environnement ou options de la ligne de commande.

Qui est prioritaire sur qui ? qui est volatile ? qui est persistent ?

Option ? non -> ENV ? non -> config.yaml ? non -> default -> logiciel

C’est pour éclaircir ce cycle de vie que j’ai créé un sujet dédié :

Oui pour la conf des modules.

Mais du coup, pourquoi faire des fichiers de conf lisibles et modifiables par un humain en les gardant en JSON ? Soit tu « interdis » leur écriture (fichiers binaires par ex.) soit tu admets que l’utilisateur doit pouvoir le lire/le modifier et alors je trouve YAML plus adapté.

Après, je ne vais pas entrer en croisade pour ça, je suggère c’est tout :slight_smile:

Parce que historiquement le fichier de conf est en json, c’était d’ailleurs ton choix :wink:
Et n’ayant pas rencontré de problèmes avec le format json je ne me suis pas posé la question de changer éventuellement de format.

Oui je pourrais passer en binaire, mais ça rendrait le débogage et le support plus difficile. Pour faire du support c’est pratique de demander à l’utilisateur de nous fournir un cat de son fichier de conf.
Alors oui on pourrait développer un outil pour permettre l’export du fichier dans un format lisible par un humain, mais ce serait du temps de dev à consacrer, une ressource précieuse que je préfère consacrer à améliorer ce qui marche mal, cf roadmap 2021 :slight_smile:

Eh bien oui, j’ai mis le format JSON mais c’était par facilité d’une part, et par méconnaissance du YAML à l’époque d’autre part.

Disons que comme là on a encore le temps de passer en YAML par défaut (et que la sérialisation doit être tout aussi simple que pour le JSON en Rust - je suppose) alors si j’ai le temps je pose une MR.

Après, elle est acceptée ou pas, pour l’instant je n’entends pas tellement d’arguments contre. J’en donne un quand même : avec Duniter 1.7 le fichier est constamment réécrit. Si Duniter 1.9 veut faire la même chose, alors le YAML perd de l’intérêt notamment au regard des commentaires qui pourraient se voir écrasés.

1 « J'aime »

Oui c’est simple, à noter que ça demanderait une dépendance en plus. La lib pour parser le json resterait de toute façon quoi qu’il arrive car j’en ai besoin pour gérer les chunk de blocs en json pour la sync locale.
Bon c’est un argument faible, mais j’essaye de n’ajouter une dépendance qui n’est pas déjà dans le projet que si la plue-value me semble valoir le coup par rapport à ce que ça rajoute en temps de compilation et en taille du binaire :slight_smile:

Je ne le savais même pas, et je n’ai pas touché à la portion de code qui fait ça, donc c’est très probablement toujours le cas :slight_smile:

Si tu prends le temps de la testée convenablement et qu’il semble ne pas y avoir de régression, oui je mergerai. Je dis juste que je ne le ferai pas moi-même :slight_smile:

1 « J'aime »

Je viens de basculer mon nœud sur l’image docker de dev.

Ça fonctionne bien, mais j’ai des blocs invalides qui m’empêche de suivre les leaders (dont je faisais fièrement partie !) . Pas grave, je ferais un reset sync… :sweat_smile:

J’ai poussé plus loin et ajouté la config GVA dans le dossier adéquate via Ansible et je crois que ça fonctionne aussi :

vit@K72Jr:~/Documents/dev/ansible/home$ curl 'https://vit.fdn.org/gva' -H 'Accept: application/json' -H 'Connection: keep-alive' -H 'DNT: 1' -H 'Origin: https://vit.fdn.org' --data-binary '[{"query":"{balance(script: \"D9D2zaJoWYWveii1JRYLVK3J4Z7ZH3QczoKrnQeiM6mx\") {amount}}"},{"query":"{balance(script: \"Do99s6wQR2JLfhirPdpAERSjNbmjjECzGxHNJMiNKT3P\") {amount}}"}]' --compressed

[{"data":{"balance":{"amount":2848179}}},{"data":{"balance":{"amount":1351650}}}]

Par contre, comment faîtes vous pour le playground ? Faut-il installer quelque chose ? Faut-il configurer nginx de façon particulière ?

On ne fait rien. Duniter sert le playground en GET sur http://host:port/path :wink:

Bon c’est surtout @poka qui voulait plein de nœuds GVA pour pouvoir tester son algo de découverte du réseau dans ğecko.
Mais le problème c’est que là je suis dans une phase de dev qui rend le déploiement de nœuds bien trop compliqués. Il serait préférable d’attendre quelques semaines que je puisse avoir le temps de :

  • trouver le schéma de db gva qui va bien pour pouvoir fournir les chunk compressés
  • migrer la db des fiches de peer
  • coder dans gva les requetes qu’il faut pour pouvoir se sync
  • coder le client gva de sync

Comptez 2 à 3 semaines.

Enfin faites comme vous voulez, mais vous êtes prévenu, c’est pas le bon moment pour moi pour que plein de gens lances des nœuds de dev vu sur quoi je travaille ces jours-ci.

2 « J'aime »

Pas de souci. N’hésite pas si tu as besoin de testeurs pour la synchro.

2 « J'aime »

Moi non plus, avec un Raspberry PI 4Go de RAM. Par contre avec mon laptop et ses 8Go de RAM, ça passe sans problème.

Dans mon cas (peut-être aussi Moul), c’est autre chose. La stack (Duniter 1.8.0) :

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x35e6ae9c]
Security context: 0x313926ed <JSObject>
    1: ruleIndexCorrectCertificationExpiryDate [0x249ba60d] [/opt/duniter/app/lib/indexer.js:~1631] [pc=0xa53f7ab8](this=0x249a6a61 <JSFunction Indexer (sfi = 0x4c08b2ad)>,HEAD=0x9270d789 <DBHead map = 0xadc169d5>,cindex=0x44d9445d <JSArray[0]>,dal=0x2fc23ad1 <FileDAL map = 0xb37d21d9>)
    2: quickCompleteGlobalScope [0x249b9e01] [/opt/duniter/app/lib/indexer.js:~3...

Mais bon la stack change à chaque fois. Pour moi c’est un soucis de mémoire.

Je n’ai pas essayé avec un Duniter plus récent, je le ferai peut-être demain.