Cahier de test Duniter 1.7.7 (Release Candidate)

Cahier des test Duniter-ts 1.7.7 (Release Candidate)

La release 1.7.7 est disponible au téléchargement sur le gitlab : v1.7.7 · Tags · nodes / typescript / duniter · GitLab

Ce document énumère les points qui doivent être testés manuellement avant de marquer une version 1.7.7 comme “stable”.

N’installez la version 1.7.7 qu’à des objectifs de validation pour le moment. Nous vous préviendrons si la release peut être installée par tout le monde sur le réseau.

Installation

Taille du fichier

  • La taille du fichier duniter-server .deb x64 ne doit pas dépasser 50 Mo
  • La taille du fichier duniter-server .deb ARM ne doit pas dépasser 70 Mo
  • La taille du fichier duniter-desktop .deb x64 ne doit pas dépasser 130 Mo
  • La taille du fichier duniter-desktop .tar.gz x64 ne doit pas dépasser 130 Mo
  • La taille du fichier duniter-desktop .exe x64 ne doit pas dépasser 100 Mo

Utilisabilité

  • [*] Le programme duniter-server est utilisable sur Debian avec le paquet .deb x64
  • [*] Le programme duniter-desktop est utilisable sur Debian avec le paquet .deb x64
  • Le programme duniter-server est utilisable sur sur ARM avec le paquet .deb ARM
  • Le programme duniter-desktop est utilisable sur GNU/Linux avec le paquet .tar.gz x64
  • Le programme duniter-server est utilisable sur GNU/Linux par compilation manuelle
  • Le programme duniter-desktop est utilisable sur Window avec le paquet .exe

Dossiers d'installation

  • [*] L'installation de Duniter ne crée pas de dossier $HOME/.config/duniter
  • [*] Le paquet Debian remplace tout le contenu du dossier /opt/duniter

Commands

duniter reset data

  • [*] Duniter should be able to reset its data.

duniter sync g1.duniter.org:443

  • Duniter should be able to synchronize on this mirror peer.

duniter direct_start

  • Duniter should be able to start with interactive execution. Should be stoppable with Ctrl+C.

duniter start

  • [*] Duniter should be able to start in daemonized way.

duniter status

  • [*] Duniter should be UP and running after duniter start.

duniter stop

  • [*] Duniter should be able stoppable after duniter start.

duniter webstart

  • [*] Duniter should be able to start in a daemonized way with its UI available at http://localhost:9220.

Behavior

Duniter must respect a set of behaviors once started.

Memory consumption

  • [*] Duniter must have a footprint of ~700MB in memory. If this amount grows, there is a memory leak.
  • Duniter Desktop must have a footprint of ~850MB in memory. If this amount grows, there is a memory leak.

New blocks detection

  • [*] Duniter should detect eventual new blocks available on the network on its startup, pull and add them to its HEAD branch.

Main blocks

  • [*] Duniter should be able to receive and add new valid blocks for the HEAD of its blockchain.

Fork blocks

  • Duniter should be able to receive fork blocks, i.e. blocks that does not push on the top of its blockchain and whose number is < HEAD.number - forkWindowSize.

forkWindowSize is the value given at URL / of each node, for example https://g1.duniter.org/

Network detection

  • [*] Duniter should be detected by the existing network. As soon as the node is UP, it should be known and UP by the node it was synced with (in the tests, g1.duniter.org:443).

Fork resolution

  • Duniter should be able to resolve forks, i.e. switch on a branch that does not contain HEAD but which is taller than HEAD branch by at least:

  • 6 blocks

  • 30 minutes of medianTime field

A technique to test this:

duniter reset data
duniter sync g1.duniter.org:443
duniter gen-next --submit-local

Then wait for the local block to be computed, as well as the network block. This way, the local node should have a different HEAD than the network. Starting the node shoul show a fork on the network with only our node.

After ~30 minutes, the fork should be resolved.

Bloc computation

  • [*] The node should sucessfully compute one block.

Interface graphique

  • [*] La nouvelle version s'affiche bien dans la barre de titre
  • [*] Lorsque la fenêtre (duniter-desktop exclusivement) est redimensionnée, l'application conserve ces dimensions même après un redémarrage du logiciel.
  • [Home] Changer pour une version plus récente conserve les données (nom de monnaie, current block, …)
  • [*] [Home] La tuile [Connected peers] s'incrémente rapidement à une valeur positive après le démarrage
  • [Home > Network > WS2P Connections] Le nœud se connecte bien au réseau, avec des connexions entrantes (INCOMING) et/ou sortantes (OUTCOMING) selon la configuration réseau demandée.
  • [Home > Network > WS2P Connections] Le nœud liste les nœuds privilégiés sur fond violet
  • [Home > Network > WS2P Connections] Le nœud liste les nœuds préférés sur fond vert
  • [*] [Home > Network > Network view] En version >= 1.6, le nœud est visible dans la liste.
  • [*] [Home > Network > Network view] En version >= 1.6.15, le nœud affiche une valeur pour la colonne [Step]*
  • [*] [Home > Network > Network view] En version >= 1.6.15, le nœud affiche une valeur “WS2P[O…][I…]” pour la colonne [API]*
  • [*] [Home > Network > Network view] En version >= 1.6.15, le nœud affiche une valeur pour la colonne [Free Rooms]*
  • [Home > Network > Network view] En version >= 1.6.16, le nœud modifie la valeur de la colonne [Free Rooms] à mesure que des connexions entrantes (INCOMING) s'ajoutent à la liste [WS2P Connections] et à l'occasion d'un changement de valeur du champ [HEAD] (se produit lorsqu'un nouveau bloc arrive).*

* Alors attention : si le HEAD transite par ne serait-ce qu'un seul noeud de version <= 1.6.14 avant d'arriver jusqu'a votre noeud vous verrez le HEAD dégradé au format v1 quelque soit la version du noeud émetteur, cela est parfaitement normal.

Transverse

  • [*] Le nœud reste synchronisé avec le réseau, et reçoit en quasi temps-réel les nouveaux blocs.
  • Le nœud reçoit correctement les transactions, et tente de les inclure dans un bloc.
  • Le nœud ne dépasse pas, pendant toute son utilisation, les seuils de mémoire suivants :
    • 700 Mo d’utilisation pour duniter-server
    • 850 Mo d’utilisation pour duniter-desktop
2 Likes

je veux biens tester l’API BMA, via Cesium.
Cependant, pouvez vous activer BMA sur certains noeuds G1-test ? Merchii :slight_smile:

Je vois plein d’édition de la check list mais celle ci ne bouge pas… C’est normal ?

Test KO de mon côté, le fichier fait 55 mo. C’est certes pas critique, mais on sait justifier l’inflation de la taille du paquet ? :slight_smile:

inflation par rapport a quoi ? quantitativement au nombre d’octets ou relativement aux features disponible ?

Inflation quantitative :slight_smile:

dirais-tu qu’il y a déflation du prix de l’octet si 5Mo de plus dans le code te permette a terme d’avoir une BDD qui en fait 50 de moins ?

J’ai téléchargé et installé Duniter 1.7.7 .deb le 18/12 sur Ubuntu 16.04.
Synchro terminée au bout 45mn :hushed:, impressionnant. J’ai depuis calculé plusieurs blocks et j’étais prêt à remplir le cahier de test en cochant toutes les cases pour l’interface graphique, à part les seuils de mémoire que je ne sais pas mesurer.
Mais :thinking: je me suis aperçu ce matin que je ne calculais plus de blocks depuis le N° 181016, block que j’ai calculé et qui contenait une transaction (21/12/18 à 18H20) .
Après avoir relancé Duniter je lance la commande grep Done ~/.config/duniter/duniter_default/duniter.log
où il apparaîtrait que j’ai calculé le block 181035 mais ce n’est pas moi qui ai calculé ce bloc sur la branche courante (sûrement dans un forck !?)

Dans « Home », sur l’interface graphique, le N° de block courant est à jour et j’ai ça dans Network View


Un petit coup de main serait le bienvenu. Merci

En fait, je ne suis plus callé sur le block courrant dans l’interface graphique, je suis au 181035 (celui que je suis censé avoir calculé) au lieu du 181583. Je suppose que je suis sur un forck, dois-je attendre tranquillement?

J’ai pas vraiment compris,ma question porte plutôt sur le fait de savoir si tout ce qui est inclus dans le binaire correspond au strict nécessaire, ou si il y a du superflu, du code mort qui pourrait être nettoyé.

je troll mais aussi talentueux que soit Cedric je ne penses pas qu’il ait rajouter 5MO de code donc ça doit être dans les lib j’ai essayé de faire un diff de package.json mais je sais pas comment faire dans gitlab.

bonne chance et jme permet de faire un liens vers un autre probleme de taille. et oui ya des gens dont le but c’est d’avoir la plus petite !
GZip comparaison

2 Likes

Refait une synchro et c’est reparti !

mon noeud est en 1.7.7 avec bma d’activé. (sur G1, pas sur G1-test)
Cesium 1.2.9 tourne dessus, mais il y a visiblement des choses qui ne passent pas.

  • dans cesium-web, pas moyen de s’y connecter, mais c’était déjà le cas avec duniter 1.6.25 : Blocage d’une requête multiorigines (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://g1.1000i100.fr/node/summary. Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant. Ça doit être un souci de config de mon reverse-proxy nginx.
  • dans cesium-desktop je n’ai plus que le DU quand je regarde mes transactions.
  • dans cesium-desktop coté annuaire, c’est vide pour les nouveau membres.

C’est tout ce que j’ai constaté pour l’instant.

Aie. C’est une régression sur BMA. Les appels à /tx/history/<from>/<size> ne retournent rien. Une idée @cgeek ? Est-ce que l’historique est encore accessible en V1.7 ? je ne sais plus ce que tu m’avais dit.

cette fois c’est /wot/newcomers. Mais j’ai l’impression que ca fonctionne en v1.7.8

Ah oui, désolé. En fait c’est optionnel désormais et par défaut c’est désactivé pour libérer de l’espace et synchroniser plus rapidement. Je vais repasser g1.duniter.org en 1.6.25 demain, ça corrigera les lenteurs observées par @PiNguyen et rétablira aussi l’historique des transactions.

Avec la 1.7 il faut ajouter l’option --store-txs pour indexer les transactions des blocs synchronisés.

Oui. Régression sur l’indexation lors de la synchro également (comme /with/ud), mais corrigé en 1.7.8.

On me fait la remarque que la dernière release est la 1.7.7 sur le Wiki https://git.duniter.org/nodes/typescript/duniter/wikis/Releases

Petite remarque intéressante : avec le mode --store-txs la synchro prend littéralement autant de temps sur Nordstrom (16 coeurs, 32 go de ram) que sur mon serveur maison (Core2Duo, 2 go de ram)

J’ai lancé les deux synchro en meme temps, et elles progressent exactement à la même vitesse.

2 Likes

C’est le HDD qui est sollicité avec cette option. C’est aussi ce qui ralentit la synchro de la 1.6.

Petit rappel de chiffres :

~Volumétrie au 24/11/2018
1,582 devenus membres
13,719 certifications
354,236 sources de monnaie
15,211 transactions

Stocker ces 15,211 transactions, et notamment les indexer, ça sollicite le disque. Il est certainement possible d’améliorer cette procédure de stockage d’ailleurs, notamment il n’y a pas d’insertion en masse je crois.

2 Likes