Amélioration de la configuration de Duniter

vit · 16 May 2021 08:10

La configuration de Duniter (1.8.x) se fait par plusieurs moyens :

Dynamiques

Variables d’environnement
Options de la ligne de commande

Persistent

Fichier config.json

Pour configurer ce fichier, on dispose de :

Assistants de configuration interactifs dans la console
Interface graphique web

Problèmes

Pour certaines configurations spécifiques ou lorsque l’interface graphique a des bugs, on est amené à écrire directement dans le fichier config.json.
Duniter écrit aussi dans ce fichier pour ses besoins (WS2P UID par exemple).
Duniter se sert aussi de ce fichier pour vérifier des règles de la monnaie, alors que les paramètres sont dans le bloc 0.

Pour ma part, je propose :

Séparation du fichier des configurations de l’utilisateur (config.json) de celui des données crées par Duniter (duniter.json ou database).
Supprimer les paramètres de la monnaie du fichier (utiliser le bloc 0).
Fichier config.json uniquement modifié par les assistants ou l’interface graphique.
Si besoin, ajout d’un fichier config.yaml configurable manuellement par l’utilisateur (dont les infos sont ajoutées au fichier config.json au lancement).

Cycle de vie de la configuration

Option cli ? non -> ENV ? non -> fichier.yaml ? non -> default -> logiciel

ou

ENV ? non -> Option cli ? non -> fichier.yaml ? non -> default -> logiciel

@elois, je mets ce billet en wiki pour que tu puisses le modifier si besoin et qu’on y ajoute des liens vers des tickets (à créer) pour améliorer la configuration de Duniter, à partir des suggestions de tous.

ljonathanl · 16 May 2021 11:48

Si les paramètres de la monnaie sont modifiés (je sais ça va pas arriver tout de suite…), comment le serveur Duniter va s’adapter ?

Je suis désolé si c’est HS

vit · 16 May 2021 12:02

Non, les paramètres d’une monnaie sont dans le bloc Zéro de la blockchain et ne changeront jamais, c’est pour cela qu’ils n’ont rien à faire dans la config. Historiquement, je crois, c’est parce que Duniter peut gérer des monnaies différentes (g1 et g1-test). Mais comme il ne gère qu’une seule blockchain, on en revient au même point. Ils ne sont pas nécessaires dans la config.

elois · 16 May 2021 12:58

Houla heu ça demande beaucoup de changements et principalement sur la codebase nodejs que je maîtrise pas et que le ne souhaite pas modifier substantiellement. Je ne pourrais pas faire ce que tu demandes.

En théorie l’utilisateur ne doit pas modifier le fichier de config lui-mnême, il doit passer par liqnterface graphique où la ligne de commande ou les env var.

De mon côté j’ai déjà travaillé sur la possibilité de tout configurer par variables d’environnement. Et je prévois de travailler sur une nouvelle interface graphique qui permettra de tout configurer sans avoir à modifier le fichier de conf. Je peux également améliorer la cli.

Mais je ne peux pas faire les changements structuraux que tu demandes dans ce post, car ce serait trop de choses à faire coter nodejs, je souhaite toucher le moins possible à la partie nodejs, déjà pour limiter les régressions et aussi parce que ma priorité c’est la migration.

vit · 16 May 2021 17:59

Peux-tu créer un nouveau sujet s’il te plaît ?

vit · 16 May 2021 18:07

Je sais bien que cela touche au nodeJS et que tu ne veux pas y toucher.

Cela n’empêche pas de faire le point sur les défauts de la configuration actuelle qui impacte directement les utilisateurs.

Cela permet à tout le monde de mieux comprendre le sujet et de faire des propositions. Certaines seront faisables rapidement, d’autres non. Mais il est bon de savoir vers quoi il serait souhaitable d’aller.
Quand on aura les ressources pour y arriver on le fera.

vit · 17 May 2021 16:40

Je duplique mon post dans ce sujet pour le compléter…

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

De plus, si le fichier est configurable par un humain, je propose d’utiliser le format yaml, plus pratique.

Dans l’idéal donc : gva.yaml

enabled: true,
ip4: 0.0.0.0
ip6: "::"
port: 30901
path: gva
subscriptions_path: gva-sub

remote:
  host: domaine.tld
  port: 443
  path: null
  subscriptions_path: null
  tls: null

whitelist:
  - "::1"
  - "127.0.0.1"

elois · 17 May 2021 16:46

Je ne suis pas en accord avec cette logique. Pour moi, on doit faire en sorte que l’utilisateur n’est jamais à modifier un fichier de conf lui même.

Je distingue 3 types d’utilisateurs de Duniter :

L’utilisateur qui préfère passer par une interface graphique il va le plus souvent utiliser la variante desktop, ou la variante server mais que les commandes sync et start puis va utiliser l’interface web d’administration pour configurer son serveur.
L’utilisateur de l’image Docker. Dans ce cas il est d’usage de tout configurer par variable d’environnement. Ces variables d’environnement pouvant elle même être déclarée dans un fichier .env où autre nom au choix.
L’utilisateur de la variante cli, dans ce cas il va utiliser les ligner de commandes fournies pour configurer son noeud.

Dans tous les cas, il ne devrait jamais être nécessaire de modifier vous-même un fichier de conf.

Si tu as actuellement des cas où tu es obligé de le faire, liste-les-moi et je ferai au mieux pour que ce soit configurable via cli/env/gui

vit · 17 May 2021 16:53

Donc ce que tu appelles des fichiers de config en les nommant .conf n’en sont pas. Et il faut interdire leur modification par l’utilisateur car ce sont des base de données de stockage du logiciel.

Bon du coup je rapatrie mon hiatus de l’autre sujet :

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, peu importe comment tu le modifie (UX ou autre).

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éé ce sujet dédié.

elois · 17 May 2021 17:04

Je suis d’accord sur le fond. Dans la pratique, les choses sont ainsi pour des raisons historiques liés aux choix de cgeek, pas aux miens.

De mon côté, une telle remise à plat ne serait possible que vers la fin de la migration, soit pas avant plusieurs années.

vit · 17 May 2021 17:11

On peut quand même créer des tickets dans un jalon dédié (on fait ça sur DuniterPy) pour des travaux qui ne sont pas prioritaires pour toi, ou qui sont en NodeJS, mais qui, lorsque les ressources et le temps le permettront pourront être repris et contiendront le résultats de nos réflexions pour ne pas les perdre.

Serais-tu d’accord pour un jalon « nodeJS » pour les tickets qui concerne la partie NodeJS ?
Un jalon backlog pour les tickets non prioritaires pour toi mais que d’autres pourraient résoudre ?

Créer des jalons comme des catégories pour les tickets te permet d’accepter des tickets sans te sentir submergé, en les déplaçant dans les jalons appropriés.

Qu’en penses-tu ?

elois · 17 May 2021 17:13

Oui bien sûr

Oui

Il y a déjà un jalon Horizon qui joue ce rôle : Horizon · Milestones · nodes / typescript / duniter · GitLab

elois · 17 May 2021 18:30

@vit autant sur le fichier conf.json historique je n’ai pas la main, autant pour les fichiers de conf des modules Rust (que GVA pour l’instant mais d’autres viendront) je peux très facilement les passer du json au yaml

Moul · 17 May 2021 20:18

J’ai une préférence du yaml sur le json qui est très sensible à la moindre typo (pas idéal quand tu démarres). J’ai une préférence pour toml (amélioration de ini) sur yaml.

Concernant, le fait de modifier manuellement le fichier de configuration. Je préfère le faire dans un fichier en dur, que de manipuler une interface graphique ou en ligne de commande. J’utilise plusieurs logiciels qui fournissent l’édition de leur fichier de conf uniquement avec un éditeur de texte (poezio, prosody, GitLab). Il s’agit principalement de services sur un serveur, ce qui est quand même le cas de Duniter.

elois · 17 May 2021 20:26

Pour les fichiers de conf des modules Rust je peux très facilement les passer en toml aussi, mais par contre je gérerai qu’un seul format donc faut vous décider

Attention ça ne concerne pas le fichier de conf historique conf.json (que je ne suis pas en capacité de modifier), je me répète exprès pour qu’il n’y ait pas de quiproquo.