Appel à lancer des noeuds gtest duniter 1.9-dev

[elois]

@vit

peux-tu ajouter dans ton premier billet la section du fichier consacrée à GVA ?

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"
  ]
}

[vit]

@elois

Le fichier est donc modules-conf/gva.conf`

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.

[cgeek]

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é

[elois]

@vit

J’aurais plutôt utilisé l’extension du format utilisé, en l’occurrence ici le json, donc gva.json

Ok je fais ça

@cgeek

J’ajouterai que j’aurais aimé le support du YAML.

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».

[vit]

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é :

Amélioration de la configuration de Duniter

La configu…

[cgeek]

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

[elois]

@cgeek

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é.

Parce que historiquement le fichier de conf est en json, c’était d’ailleurs ton choix
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

[cgeek]

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.

[elois]

@cgeek

et que la sérialisation doit être tout aussi simple que pour le JSON en Rust - je suppose

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

@cgeek

avec Duniter 1.7 le fichier est constamment réécrit.

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

@cgeek

lors si j’ai le temps je pose une MR.

Après, elle est acceptée ou pas

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

[vit]

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…

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 ?

[elois]

@vit

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

[elois]

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.

[Pini]

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

[cgeek]

@Moul

Je me rends compte qu’il n’est pas possible de finaliser la synchronisation de mon nœud sur la branche dev sur la Ğ1-test.

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.

@elois

En fait c’est plutôt des bugs dans l’algo de téléchargement des chunk, qui se déclenche notamment quand des endpoint BMA ne répondent pas.

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.

[Pini]

@cgeek

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

=> Duniter dev: ressources pour la synchro et espace disque - #16 by Pini

[poka]

J’ai une erreur concernant le port BMA avec la dernière version de duniter:dev via docker-compose.

J’ai fait un reset hard avec rm -rf /var/lib/docker/volumes/duniter-prod_data/_data/duniter_default/data/*

Au redémarrage du container j’ai cette erreur:

2021-06-30T00:33:11+00:00 - info: GVA server listen on http://0.0.0.0:30901/gva
2021-06-30T00:33:11+00:00 - info: Server::run; addr=0.0.0.0:30901
2021-06-30T00:33:11+00:00 - info: listening on http://0.0.0.0:30901 
2021-06-30T00:33:11+00:00 - info: Block resolution: 0 potential blocks for root block...
2021-06-30T00:33:11+00:00 - error: Error: BMA: no port for remote contact.
    at Object.input (/duniter/app/modules/bma/index.js:206:31)
    at Stack.processCommand (/duniter/index.js:348:65)
    at process._tickCallback (internal/process/next_tick.js:68:7)

[elois]

@poka

no port for remote contact

Il te faut setter la variable DUNITER_BMA_REMOTE_PORT

[HugoTrentesaux]

Presque deux ans après cet appel à lancer des nœuds duniter 1.9, je fais remonter le sujet pour que des gens :

• publient des noeuds 1.9 sur le réseau [edit Ğ1] (je n’en vois que deux dans Kazou)
• ajoutent dans leur whitelist un service Ğ1 stats pour pouvoir ré-obtenir des données à jour sur cet outil visiblement utile

[aya]

Pour info il y a une MR en cours qui permet de lancer un noeud duniter 1.9 sous docker.

Pour finaliser cette MR, j’ai besoin de mettre à jour les dépendances nodejs, je suis bloqué à cette étape car je ne connais pas assez npm, j’aurais bien besoin d’un petit coup de main