Appel à lancer des noeuds gtest duniter 1.9-dev

Nodes Duniter-v1
, ,
18

Quelle est la commande pour synchroniser via GVA ? C’est déjà possible ou c’est en WIP ?

19

Ce sera là même, duniter sync :slight_smile:

Non pas encore, là je développe les préparatifs indispensables pour pouvoir commencer à migrer la sync. Je dois notamment d’abord migrer la db des peers, tout est lié :wink:

1 Like
20

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. Je ne sais pas si c’est le cas avec v1.8.1. Je ne trouve plus le post qui disait que c’était un problème de manque de points d’accès BMA.

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