Appel à lancer des noeuds gtest duniter 1.9-dev

Nodes Duniter-v1
, ,
21

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.
C’est pour ça que j’ai priorisé la migration de cette partie, sur laquelle je travaille en ce moment même et qui devrait être prête d’ici 2 semaines :slight_smile:

En attendant, le seul moyen de contournement c’est de faire une sync locale à partir d’un export JSON de la blockchain. Je suis en train d’en upload un sur le cloud d’axiom …

EDIT: bon je sais pas si l’upload à marché mais voici le lien : Login – axiom-cloud

1 Like
22

@kimamila @vit @Moul @cgeek et tous ceux qui ont un noeud gtest je ne connais pas tout le monde, mais ça me serait super utile que vous passiez votre noeud en 1.9-dev au plus vite, sans ça je suis bloqué pour tester mon algo de scan réseau GVA.

23

Pour ceux qui ont déjà un noeud de dev et qui voudrait le maj: le commit 99f255a9 a modifié l’architecture de toutes les bases de données.

En théorie vous devez :

  • Supprimer les dossiers dunp_v1_sled et txs_mp_v2_sled (dans data)
  • Faire un dex migrate

Le tout nœud Duniter éteint bien entendu.
Je dis en théorie, car je suis en train de tester en essayent de maj un de mes nœuds de dev, si possible, je vous recommande d’attendre que j’y arrive avant de maj vous-même (Soit attendre lundi car là il est tard et je peux pas bosser dessus demain).

Il est également possible de reset data && sync :slight_smile:

1 Like
24

Également pensez à vous manifester ici lorsque que vous avez un ou plusieurs noeuds gtest GVA, avec leur URL, que je puisse remplir mon boostrap gecko.

Je mettrais à jour le premier message de ce topic avec tous les noeuds gtest manifesté au fur et à mesure :slight_smile:

1 Like
25

Tu peux déjà ajouter les miens du coup :slight_smile:

https://gt.elo.tf/gva
https://gt.librelois.fr/gva
1 Like
26

@Pini bug corrigé : Merge branch 'bma-ep-env' into 'dev' (e15b7782) · Commits · nodes / typescript / duniter · GitLab

2 Likes
27

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 ?

28

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 ?

29

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 Like
30

Et

Et le mien :

https://g1-test-dev.pini.fr/gva
3 Likes
31

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 Likes
32

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 Likes
33

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

34

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:

35

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:

36

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

37

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

38

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:

39

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:

40

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 Like