Bootstraper une ĞDev (runtime-400)

Nodes Duniter-v2s
,
18

J’ai commencé à compléter la documentation docs/dev/launch-a-live-network.md avec les notes prises lors de notre session il y a 9 jours. (ticket #91, MR !114)

Je suis désolé de devoir te redemander certaines choses que tu m’as déjà expliqué, je n’ai pas réussi à prendre des notes assez précises. Voici donc mes questions :

répartition des tâches automatisées

les tâches sont réparties suivant plusieurs systèmes

  • des CI GitLab
    • sur master
      • build_release_manual
      • deploy_docker_release_sha
    • sur release
      • build_release
      • deploy_docker_release_tag
  • des scripts xtask
    • release-runtime
    • inject-runtime-code
  • des scripts bash
    • gen-live-network-raw-spec.sh
    • create-live-network.sh
  • des appels docker
    • key generate
    • key generate-session-keys

est-ce que certaines de ces tâches sont appelées à changer ? Par exemple migrer des scripts bash vers des xtask, ou générer les session keys du premier nœud dans une xtask.

à propos de docker

Dans la pipeline de publication des images docker, je vois

WARNING! Using --password via the CLI is insecure.

Où peut-on voir l’ensemble des images docker ? Que contiennent-elles (client sans runtime, client avec runtime, runtime…) ? Que fournit-on aux smith comme docker-compose.yml ? Quand donne-t-on l’information du bootnode (adresse ip / dns par exemple) ?

rotation des session keys

Quelle est la méthode recommandée pour remplacer les session keys de l’autorité genesis ? Via l’API RPC contactée par polkadotjs sur tunnel ssh ?

que fournit-on aux smith ?

Quand on est prêt à ce que les autres smith rejoignent le réseau, que leur fournit-on ?

  • le nom d’une image docker ?
  • un bootnode ?

Par quel biais obtiennent-ils les session keys de notre autorité ?

processus général

Je ne suis pas sûr d’avoir bien compris l’ordre des étapes. Est-ce le suivant ?

  1. compilation du runtime avec srtool (+ publication, + publication image docker)
  2. génération locale des session keys de l’autorité du genesis, ajout dans les chainspec, génération des raw chainspec (mais avec le binaire du runtime compilé sans srtool)
  3. injection du runtime compilé avec srtool dans les raw chainspec
  4. lancement du nœud validateur avec ces raw chainspec
  5. rotation des session keys
  6. appel aux smith pour qu’ils démarrent leurs noeuds validateurs