GDev Runtime 700

tuxmain · 20 November 2023 11:11

J’ai ajouté 8Go de swap et toujours OOM. Idem en retirant toutes les options optionnelles.

$ duniter --chain gdev700.json
2023-11-20 11:51:15 Duniter    
2023-11-20 11:51:15 ✌️  version 0.7.0-c4773062fb5    
2023-11-20 11:51:15 ❤️  by Axiom-Team Developers <https://axiom-team.fr>, 2021-2023    
2023-11-20 11:51:15 📋 Chain specification: ĞDev    
2023-11-20 11:51:15 🏷  Node name: tuxmain-polux-smith-gdev    
2023-11-20 11:51:15 👤 Role: AUTHORITY    
2023-11-20 11:51:15 💾 Database: ParityDb at /home/pi/.local/share/duniter/chains/gdev/paritydb/full    
2023-11-20 11:51:15 ⛓  Native runtime: gdev-700 (duniter-gdev-1.tx1.au1)    
Error: Service(Client(Backend("IO Error: Out of memory (os error 12)")))

Il y a plusieurs issues sur Polkadot/Substrate à propos d’OOM ou de fuites mémoires mais seulement dans certaines phases de consensus, et jamais avec ce message. J’essaie de trouver d’où ça vient mais il faudrait arriver à installer valgrind ou lldb en arm64 (les dépôts raspbian bullseye sont uniquement en armv7).

Edit: C’est dans sc_service::new_full_parts, à cause du backend db. D’ailleurs ne comprends pas pourquoi les builds armv7 marchent puisque parity-db ne supporte que x86-64 et aarch64.

Edit: Finalement ça marche après suppression de l’ancienne db. C’est tout de même un bug de parity-db.

vit · 20 November 2023 11:43

Il y a un problème chez moi avec la commande pour purger la chaîne :

Dans le container, /var/lib/duniter pointe sur mon dossier de données contenant chains/gdev/paritydb/full et pas .local/share/duniter/chains/gdev/paritydb/full

docker exec -ti home_duniter_validator.1.nalo348fqf89gavs2joq40c48 duniter purge-chain --chain=gdev
Are you sure to remove "/var/lib/duniter/.local/share/duniter/chains/gdev/paritydb/full"? [y/N]: y
"/var/lib/duniter/.local/share/duniter/chains/gdev/paritydb/full" did not exist.

Dans telemetry, je ne vois que mes deux nœuds en 0.7.0. Et seul le validator avance sur une nouvelle chaîne de blocs, le RPC reste sur l’ancienne…

cgeek · 20 November 2023 12:03

Le fichier a bien été produit mais j’ai oublié de l’ajouter aux assets de la release. C’est corrigé dans le code et corrigé dans la release.

Oui, les tables LevelDB du dump indiquent : #657075.

Tout le détail se trouve dans les logs de ce job.

Il est dans les fichiers de la release, ça fait partie des livrables

Je préfère qu’il soit dans la release plutôt que les fichiers d’input, puisque précisément ce n’est pas un fichier d’entrée mais un fichier intermédiaire généré par la CI dans son processus de création de la release.

Tu as raison, je vais éditer mon post plus haut, il faut lancer avec l’option -d /var/lib/duniter :

purge-chain --chain=gdev -d /var/lib/duniter

HugoTrentesaux · 20 November 2023 12:15

Je ne comprends pas tout à fait comment fonctionne la CI, mais a priori on ne publie les specs qu’une fois (au démarrage d’un réseau) alors qu’on peut faire des publications de runtime régulièrement (pour mettre à jour le réseau). Est-ce que comme tu l’as fait ces fichiers seront ajoutés à chaque release de runtime ou uniquement au démarrage d’un nouveau réseau ?

Chouette, facile, à retenir en plus ><

12 certifications expirées (normal en 30 minutes)
5319 adhésions expirées, pas la peine de les afficher toutes, uniquement les adhésions qui n’étaient pas expirées au bloc de l’export
actual monetary_mass (8,457,743,556) and initial_monetary_mass (8,457,771,775) do not match soit 28219 de différence, ~ ok pour 282 Ğ1

cgeek · 20 November 2023 12:24

Comme pour l’instant nous sommes susceptibles de redémarrer régulièrement le réseau, la CI builde tous les fichiers à chaque release. Ensuite libre à nous ensuite de mettre à jour les raw-specs dans le code (étape 3) puis de relivrer une image Docker du Client (étape 4, voir le détail des étapes).

Mais effectivement à terme, la plupart des fichiers ne seront plus à livrer.

poka · 20 November 2023 13:57

2 posts were merged into an existing topic: Ğecko talks / user support

Moul · 20 November 2023 14:51

DU réévalué maintenant et à une valeur de 14.00 ĞDev c’est correct selon les paramètres qui ont été choisis je suppose ?

Oui

HugoTrentesaux · 20 November 2023 15:58

On ne s’est pas bien compris quand j’ai retravaillé sur le format du genesis de l’indexeur. Je n’utilisais pas la struct custom GenesisIndexerExport, mais les chainspecs au format json (mais pas raw). En gros j’utilisais la sortie de duniter build-spec (pas la sortie de duniter build-spec --raw ni la sortie optionnelle quand la variable d’environnement DUNITER_GENESIS_EXPORT est définie). Donc ce qu’il me manque là si je ne veux pas changer le format d’entrée de l’indexeur, c’est bien les specs au format json (pas raw).

Je pourrais peut-être partir des raw specs pour revenir au format “pas raw”, mais ce serait plus pratique de les avoir directement.

Ou alors je pourrais le re-générer si je connaissais le DUNITER_GENESIS_TIMESTAMP puisque ça devrait être déterministe, mais je ne connais pas cette valeur. Je pourrais essayer de rétro-ingénierer cette valeur, mais ce n’est pas très propre.

[edit] je pars pour l’instant de ce timestamp : 1700388302

cgeek · 20 November 2023 16:20

Ce fichier est aussi sur la page de releases : fichier gdev.json.

HugoTrentesaux · 20 November 2023 16:25

Ok, en fait j’avais juste pas les yeux en face des trous ! Merci
On devrait pouvoir le recréer en faisant :

duniter build-spec --chain ./node/specs/gdev-raw.json 1> ./node/specs/gdev.json

mais curieusement ça donne un fichier raw

cgeek · 21 November 2023 12:59

Je me suis trompé, désolé, c’était plutôt #679340 (l’autre valeur, c’était le dump que j’avais fait le 31/08/2023).

Le n° de bloc, ainsi que son medianTime seront désormais consignés par py-g1-migrator.

Il me manquait l’information du bloc courant à au moment de la génération du Genesis pour pouvoir faire ce filtre. Étant donné le point ci-dessus, j’ai pu apporter un correctif.

La valeur précise peut se déduire des logs, notamment ceux qui indiquent “Building chain spec” :

2023-11-19 10:04:34 Building chain spec

Le timestamp précis serait donc plutôt autour de 1700384674 . Mais après quelques essais, je n’ai pas réussi à le reproduire localement. [edit] : ah oui, je n’ai pas testé avec le Runtime produit par srtool, c’est pour ça.

En tout cas, j’ai créé la MR!199 pour finaliser la release et merger les modifications apportées durant le processus. Je t’invite à la relire.

HugoTrentesaux · 21 November 2023 13:04

Super super ! On commence a avoir lissé pas mal de rugosités, je continue de travailler sur les indexeurs parce que j’en tirerai sûrement quelques retours et je ferai une relecture à froid plus tard, il n’y a pas d’urgence à merge ça.

HugoTrentesaux · 21 November 2023 13:16

J’ai implémenté ChangeOwnerKey dans Ğcli (en deux minutes, par copier-coller de link account), et ça me permet de me rappeler une autre raison pour laquelle on migrait les identités des forgerons dans le genesis :

gcli -S cesium identity change-owner-key -s "... mon mnemonic ..."   
Cesium id: 
Cesium password: 
transaction submitted to the network, waiting 6 seconds...
Pallet error: SmithSubWot::NotAllowedToChangeIdtyAddress

Les forgeons n’ont pas le droit de migrer leur identité.

Donc je suis partagé entre deux solutions :

révoquer mon adhésion forgeron, migrer mon identité, puis redemander l’adhésion forgeron
devenir forgeron avec ma clé actuelle

L’inconvénient de la deuxième option est que je ne pourrai pas utiliser mon identité dans polkadotjs app, donc il faudra que j’implémente tout dans Ğcli. Je pense donc partir sur la première option.

poka · 21 November 2023 13:22

Oui c’est la principale raison qui m’avait poussé à permettre le switch des adresse v1/v2 dans py-g1-migrator, pour que les smiths puissent utiliser gecko.

tuxmain · 21 November 2023 13:24

On peut aussi essayer de permettre aux forgerons de changer de clé. Le problème devait être lié à la mise à jour du storage des authority-members ? Peut-être qu’avec le nouveau mécanisme de lien identité<->compte ce serait plus simple ? La seule condition serait d’être offline.

Un gros problème aussi est que l’extension PolkadotJS ne permet pas d’importer une clé privée qui n’a pas été générée avec un mnemonic. Sinon on pourrait tout faire avec le client PolkadotJS.

HugoTrentesaux · 22 November 2023 12:09

@cgeek, il me semble que ton nœud a été HS récemment, donc on a loupé quelques blocs.

en dehors de ça, la blockchain est assez précise à deux forgerons

HugoTrentesaux · 22 November 2023 12:12

En vrai, ça se fait très vite, et comme les certifications forgeron sont liées à l’identité et pas à la clé, on n’a même pas besoin de redemander des certifications. Ça m’a pris quelques minutes, tout est implémenté dans Ğcli sur ma branche, je ferai une démo vidéo.

cgeek · 22 November 2023 15:55

Je ne pense pas, il n’y a eu aucun restart de noté sur le pod et la machine n’a pas rebooté non plus. Par contre j’ai pu perdre la connexion Internet, et si tu étais déjà passé autorité à ce moment-là, ça peut expliquer le loupé.

vit · 23 November 2023 16:14

J’essaie aussi de transférer mon identité et ma monnaie de mon compte V1 à mon compte V2, mais :

ERROR:root:{'type': 'Module', 'name': 'NotAllowedToChangeIdtyAddress', 'docs': ['Not allowed to change identity address']}

Je veux bien la liste des calls que tu vas faire pour révoquer ton adhésion forgeron, voir si je peux l’implémenter dans Tikka…

HugoTrentesaux · 23 November 2023 18:13

Yes, ça fait un moment que je voulais vous mettre la liste des calls, mais j’ai été aspiré par subsquid. Mais ça nous permet de voir l’historique (sans ça j’aurais pas pu retrouver) :

Requête

sur https://subsquid.gdev.coinduf.eu/graphql
tous les calls en succès des pallets SmithMembership, Identity et AuthorityMembers

query Query {
  calls(limit: 10, orderBy: block_height_ASC,
    where: {success_eq: true,
      AND: {pallet_eq: "SmithMembership",
        OR: {pallet_eq: "Identity",
          OR: {pallet_eq: "AuthorityMembers"}}}}) {
    block {
      height
    }
    pallet
    name
    success
  }
}

(j’ai pas encore ajouté la caller, on pourrait raffiner le filtre, mais là ça nous suffit)

Réponse

{
  "data": {
    "calls": [
      {
        "block": {
          "height": 14646
        },
        "pallet": "Identity",
        "name": "link_account",
        "success": true
      },
      {
        "block": {
          "height": 30420
        },
        "pallet": "SmithMembership",
        "name": "revoke_membership",
        "success": true
      },
      {
        "block": {
          "height": 30504
        },
        "pallet": "Identity",
        "name": "change_owner_key",
        "success": true
      },
      {
        "block": {
          "height": 30516
        },
        "pallet": "SmithMembership",
        "name": "request_membership",
        "success": true
      },
      {
        "block": {
          "height": 30525
        },
        "pallet": "SmithMembership",
        "name": "claim_membership",
        "success": true
      },
      {
        "block": {
          "height": 30630
        },
        "pallet": "AuthorityMembers",
        "name": "set_session_keys",
        "success": true
      },
      {
        "block": {
          "height": 30776
        },
        "pallet": "AuthorityMembers",
        "name": "set_session_keys",
        "success": true
      },
      {
        "block": {
          "height": 30801
        },
        "pallet": "Identity",
        "name": "link_account",
        "success": true
      },
      {
        "block": {
          "height": 30804
        },
        "pallet": "AuthorityMembers",
        "name": "set_session_keys",
        "success": true
      },
      {
        "block": {
          "height": 30813
        },
        "pallet": "AuthorityMembers",
        "name": "go_online",
        "success": true
      }
    ]
  }
}

Donc résumé :

bloc 30420 je révoque mon identité forgeron
bloc 30504 je change ma clé membre
bloc 30516 je demande l’adhésion forgeron
bloc 30525 je demande à valider mon adhésion forgeron (j’ai déjà les certifications forgeron)
bloc 30630 je set mes session keys une première fois avec Ğcli (après l’avoir implémenté)
bloc 30776 je set mes session keys une deuxième fois avec polkadotjs pour vérifier que c’est le même résultat et que je n’ai pas fait d’erreur de code qui auraient corrompu mes session keys
bloc 30813 je go_online et commence à participer deux sessions après

Tu verras en étant attentif que j’ai omis quelques calls de trucs que j’ai fait entre temps