Duniteroxyde (oxydation de Duniter)

Pour plusieurs raisons que j’expliciterai peut-être plus tard, j’ai décidé de me lancer dans un « nouveau » projet, du moins à court terme : l’Oxydation de Duniter.

Ce n’est pas tant un « nouveau » projet qu’un changement de stratégie, voici l’idée générale :

Plutôt que d’écrire une nouvelle implémentation du protocole DUBP a coté (Dunitrust), l’idée du projet « Duniteroxyde » est d’intégrer progressivement du code Rust dans Duniter via un outil de binding NodeJs<->Rust: Neon.

Cette approche a plusieurs avantages :

  • Suppression de l’effet tunnel que connaît actuellement la Ğ1 (Pendant que je dev Dunitrust je ne fais pas avancer Duniter, et en même temps Dunitrust est encore très trèèèès loin d’une v1).
  • Bénéficier de la couverture fonctionnelle offerte par les TF que possède Duniter.

Étapes

  1. Migration de wotb: en bas de ce 1er post
  2. Migration de naclb: post n°32 (lien direct)

Architecture

Le projet d’oxydation de Duniter s’étaler sur 3 dépôts git :

  1. dubp-rs-libs: contient les crates que j’extrait de Dunitrust pour les intégrer dans Duniter
  2. duniteroxyde: contient de code de binding Rust<->NodeJs (utilise neon-binding)
  3. duniter: le dépôt historique du logiciel Duniter, utilise désormais le module npm « duniteroxyde » comme dépendance.

Pourquoi n’était-ce pas envisageable dès le début ?

Pour au moins 3 raisons :

  • A l’époque, Neon était trop jeune et incomplet, le code de binding était lourd et verbeux, et faisait perdre certaines garanties du Rust (notamment la sûreté de la mémoire).
  • L’oxydation de Duniter n’était de toute façon pas possible à cause d’un problème bloquant au niveau du build pour windows (c’est juste un problème de VM pas a jours mais en 2 ans personne n’a su le régler), cf ce fils : Du Rust dans NodeJs graçe a Neon : le courant passe !
  • J’ai découvert NodeJs en même temps que la monnaie libre il y a 3 ans et demi, il y a 2 ans je n’avais clairement pas le niveau requis en NodeJs pour me lancer dans une oxydation de Duniter. Je découvrais la programmation asynchrone (moi qui avais toujours codé en synchrone), et je suis resté très mal à l’aise avec ce paradigme jusqu’à récemment.

Oxyder Duniter jusqu’où ? Quid de Dunitrust ?

Pour être franc je n’en ai absolument aucune idée, l’avenir nous le dira. Cela dépendra aussi de jusqu’où il sera envisageable d’oxyder Duniter, en concertation avec @cgeek :slight_smile:

Quant au projet Dunitrust, une grande partie du code pourrait être réutilisée plus ou moins directement dans l’oxydation de Duniter, du moins en théorie, en pratique ça dépendra des difficultés rencontrées et de jusqu’où ou souhaite aller dans l’intégration.
Les portions de code qui seront intégrés dans Duniter pourrons être « mises a l’épreuve de la prod », donc en vrai cela bénéficie aussi au projet Dunitrust d’une certaine façon.

Qu’en est t’il à court terme ?

A cours terme je vois déjà 2 étapes dans l’oxydation de Duniter que je suis en mesure de réaliser rapidement :

  1. Migration de wotb: je viens de passer 4 jours sur cette étape a quasi plein-temps (environ 30h), cela fût long car je suis reparti d’une feuille blanche (explication ici) et qu’il a fallu que je me replonge dans Neon (qui a beaucoup changé, pour le mieux) et dans NodeJs/Typescript. L’étape 2 devrait être beaucoup plus rapide.
  2. Migration de scryptb et naclb: dans une approche isofonctionelle bien entendu (donc avec gestion de la clé privée), l’objectif n’est pas de restreindre Duniter (du moins pas pour l’instant, on pourra toujours décider de le faire plus tard s’il y a un consensus en ce sens).

Étape 1 : Migration de wotb

La 1ère étape est déjà quasiment terminée, la MR est ici : https://git.duniter.org/nodes/typescript/duniter/-/merge_requests/1290 (la CI a des soucis bizarres mais les tests passent chez moi).

J’en ai profité pour externaliser la crate dubp-wot dans son propre dépôt, qui contiens également le code de binding (dans le dossier node-binding) : https://git.duniter.org/libs/dubp-wot

J’ai déjà déployé ce code sur un de mes nœuds g1-test, et tout semble bien fonctionner : ts.gt.librelois.fr
Je n’ai pas refait de sync, ce n’est pas nécessaire car le code de binding que j’ai écris est capable de lire le fichier wotb.bin d’origine. (j’ai aussi testé en faisant une sync, sur mon nœud duniter de dev en local et tout se passe bien).

J’ai également mis à jours tous les scripts de build, il faut encore que je teste chacun des paquets (variante desktop et paquet arm notamment).

EDIT: toutes les variantes ont été testées et toutes se build avec succès.


Pour tester Duniter en mode « oxydé » vous aurez besoin de Rust et d’un version précise de node, voici les commandes (a ne faire qu’une fois) :

nvm install 10
nvm use 10
curl https://sh.rustup.rs -sSf | sh -s -- -y
echo "export PATH=\"$HOME/.cargo/bin:\$PATH\"" >> ~/.bashrc
source ~/.bashrc

A partir de la 2ème fois, la commande nvm use 10 suffit.

Pour compiler Duniter, utilisez comme d’habitude la commande yarn :slight_smile:

10 J'aimes

Bravo ! Excellente approche, je trouve !

C’est vraiment une excellente nouvelle ! J’ai hâte de voir tout ce que cela va donner, mais nul doute que cela va rapidement bénéficier à la Ğ1 et accélérer les évolutions du protocole.

De mon côté je ferai de mon mieux pour faciliter cette transition.

8 J'aimes

Problème résolu : https://git.duniter.org/nodes/typescript/duniter/-/jobs/37085

La cause: Duniter utilise la lib q-io pour lire et écrire dans des fichiers. Cette lib propose un système de mock, que Duniter utilise pour ses tests unitaires.
Or, évidemment le code Rust n’utilise pas ce système, il tente donc vraiment d’écrire dans un fichier (ce qui fonctionne en local chez moi mais plante dans la CI, sans doute un problème de permissions).

La solution que j’ai choisi: ne demander a dubp-wot-rs d’écrire dans un fichier que si on est pas en mode « memoryOnly », et ça marche :slight_smile:

Ceci explique également pourquoi tout fonctionne bien dans mes tests réels, en tests réels on est pas en mode memory.

@cgeek : du coup la MR est prête :slight_smile:

1 J'aime

Je vais tenter de répondre au mieux aux demandes de MR mais je suis assez pris (à la fois pour le boulot-euros mais là suis sur le rétablissement de WotWizard).

J’essaye de regarder la MR avant demain soir.

1 J'aime

5 messages ont été fusionnés à un sujet existant : GitLab Flow ou git-flow?

Appels a testeur sur la G1-test : @Moul @vit @matograine @scanlegentil et tout ceux qui veulent bien m’aider a tester :slight_smile:

Voici les paquets debian de Duniter « oxydé », a n’installer que sur la monnaie de test évidemment, si vous pouvez tester et vérifier que tout fonctionne bien ça m’aiderais beaucoup :

Duniter-server: https://pub.librelois.fr/duniter-server-wotb-rs-linux-x64.deb

Duniter-desktop: https://pub.librelois.fr/duniter-desktop-wotb-rs-linux-x64.deb

Duniter-server pour armv7l (nécessite debian buster) : https://pub.librelois.fr/duniter-server-wotb-rs-linux-armv7l.deb

Ces paquets ont été générés avec le nouveau process de build permettant d’intégrer du Rust dans Duniter, le process de build ayant changé dans les 3 variantes, il faut toutes les tester :slight_smile:

4 J'aimes

J’ai lancé mon nœud avec ce livrable, pour l’instant ça à l’air de tourner.

1 J'aime

tranquilou pour celle-ci

1 J'aime

@cgeek @scanlegentil et tous ceux qui auraient testé les paquets debian, il y a un bug, qui ne se produit que si on restart le nœud, je viens de pousser un nouveau commit qui le corrige.
J’uploaderai les nouveaux paquets demain, en attendant ne faites surtout pas de restart, si vous en faite un vous serez obligés de reset data et resync :stuck_out_tongue:

Dans les prochains jours/semaines je vais avoir besoin de beaucoup de testeurs, et qui testent des truc tordus (genre restart son nœud sans raison).

1 J'aime

Allez balance ton plan de tests.

On m’a appelé ? :wink:
J’attends la nouvelle version. Je me ferai un plaisir de faire des import-lookup sauvages.

2 J'aimes

Echec synchro avec Duniter-desktop sur Ubuntu 18.04 64bit.

Capture du 2020-04-01 11-30-51

J’ai fermé et relancé, mais l’interface reste blanche, aucun menu, rien…

Lancé d’une console, interface blanche, mais les messages console semble dire que ça fonctionne…

2020-04-01T11:34:36+02:00 - info: WS2P: connected to peer GF5i8XE2 using `WS2P 78.207.66.161 20900`!
2020-04-01T11:34:36+02:00 - info: Block resolution: 0 potential blocks after current#542354...
2020-04-01T11:34:36+02:00 - info: Block resolution: 0 potential blocks after current#542354...
2020-04-01T11:36:01+02:00 - info: [4QzqnRe7] ⬇ PEER 238pNfpk 542328-0
2020-04-01T11:36:01+02:00 - info: [4QzqnRe7] ⬇ PEER 238pNfpk 542328-0
2020-04-01T11:36:01+02:00 - info: [4QzqnRe7] ⬇ PEER 238pNfpk 542328-0
2020-04-01T11:36:01+02:00 - info: [4QzqnRe7] ✔ PEER 238pNfpk 542328-0
2020-04-01T11:36:02+02:00 - info: [4QzqnRe7] ⬇ PEER 238pNfpk 542328-0
2020-04-01T11:36:02+02:00 - info: [4QzqnRe7] ⬇ PEER 238pNfpk 542328-0
1 J'aime

La version desktop en 1.7.21 fonctionne t’elle bien chez toi ?

Je suis en train d’installer duniter-desktop 1.7.21 sur mon poste du coup, si tout marche bien alors je testerai avec le paquet « oxydé ».


@scanlegentil @cgeek @vit c’est bon j’ai mis a jours les paquets, les url sont les mêmes mais je les redonnent quand même :

Duniter-server: https://pub.librelois.fr/duniter-server-wotb-rs-linux-x64.deb

Duniter-desktop: https://pub.librelois.fr/duniter-desktop-wotb-rs-linux-x64.deb

Duniter-server pour armv7l (nécessite debian buster) : https://pub.librelois.fr/duniter-server-wotb-rs-linux-armv7l.deb

Pour l’instant seule le module wotb a changé, donc quasiment rien, 98% de duniter est toujours comme avant. Mais avant d’aller plus loin dans l’oxydation je doit m’assurer que tout les nouveaux process de build fonctionnent bien :slight_smile:

Oui. J’ai juste une fenêtre qui indique que la version de nw est obsolete, mais la synchro fonctionne et l’interface aussi.

Je viens de retester ton build 2 fois et même échec de la synchro à 100%, puis interface blanche.
Dans la console pourtant, la synchro est bien finie…

2020-04-01T20:50:55+02:00 - info: Peer 3dnbnYY9i2bHMQUGyFp5GVvJ2wBkVpus31cDJA5cfRpj
2020-04-01T20:50:55+02:00 - info: [4QzqnRe7] ⬇ PEER 3dnbnYY9 542550-0
2020-04-01T20:50:55+02:00 - info: [4QzqnRe7] ✔ PEER 3dnbnYY9 542550-0
2020-04-01T20:50:55+02:00 - info: Sync finished.
1 J'aime

Merci @vit pour ces tests, il n’y a rien de plus dans la console ? Est ce que tu arrive a relancer duniter desktop ensuite ?
Que contient le dossier ~/.config/duniter/duniter-default ?

Est ce que ce dossier n’existait pas avant que tu installe la version desktop ? J’ai déjà remarqué des effets de bord si les variantes server et desktop utilisent le même dossier.

Si, duniter continue à tourner dans la console, seule la fenêtre de la GUI est blanche.

Relancer donne la même chose, activité console, interface blanche.

Non, j’ai un script qui nettoie tout en gardant que la config et le keyring :

Content resetted of ~/.config/duniter/duniter_default:
total 12
-rw-rw-r-- 1 vit vit 1701 avril  1 20:25 conf.json
-rw-rw-r-- 1 vit vit 1693 avril  1 10:44 conf.json.back
-rw-rw-r-- 1 vit vit  147 avril  1 20:25 keyring.yml

Retesté une 3ème fois en supprimant tout le dossier : même problème…

As-tu vérifié avec la v1.7.21 officielle ?

@vit ce n’est pas lié a desktop en particulier: c’est la web-ui. Je reproduis le problème avec duniter-server en allant sur la web-ui, j’ai souvent une page qui reste blanche après la sync, ce problème m’arrive également régulièrement en 1.7.21.

Avec duniter 1.8 c’est encore un peu plus lent (pour des raisons que j’ignore, peut être le changement de la version de node), d’où le fait que le problème se produit quasi systématiquement.

En fait c’est la web-ui (où l’api webmin) qui est vraiment trop lente, elle doit charger trop de truc au démarrage, je vois dans la console javascript qu’elle se prend un timeout :

image

@cgeek @ManUtopiK, je vois qu’il y a 9 mois vous vous étiez lancés sur le développement d’une nouvelle duniter-ui basée sur nuxtjs, pourquoi aviez-vous arrêté en si bon chemin ? Était-ce juste par manque de temps ou y avait t’il des blocages particuliers ?

Perso je suis nul en front et je n’aime pas en faire, et la web-ui est clairement quelque chose d’optionnel (certes très confortable, y compris pour moi, mais pas indispensable), donc si personne ne la reprend elle finira par sauter.

@cgeek dit moi si je me trompe mais j’avais l’impression que tu t’éclatais plus sur du front que sur du back, et que tu prenais du plaisir sur ce projet duniter-ui v2 ? Ça te dirait de te focaliser là-dessus (avec @ManUtopiK et d’autres dev front éventuellement), pendant que moi je me focalise sur le back ?

Si vous êtes motivés pour reprendre duniter-ui v2 je suis prêt à faire ce qu’il vous faut coter webmin api :slight_smile:

2 J'aimes