Pourquoi ne pas faire une image générique, sans spécifier ni le réseau ni le runtime dans l’image, qui puisse lancer n’importe quel network en fonction du --chain passé en argument, du moment que les runtimes sont embarqués ?
C’est pour économiser de la place dans l’image Docker ? Mais trois runtimes, ça ne doit pas peser si lourd que ça ?
On aurait donc :
duniter-v2s:<CLIENT>
Exemple : duniter-v2s:0.12.0
Une seule image, et des tags uniquement pour les versions du client, car il s’agit bel et bien de releases client.
Client qui embarque au fur et à mesure non seulement des corrections du code du client, mais aussi des nouveaux runtimes.
Ainsi, on sait qu’à partir du client 0.12.0, on a embarqué au client :
GDev runtime 800
GTest runtime 1100
Ca semble beaucoup plus idiomatique de la manière dont Docker fonctionne.
Non ?
Le seul truc à embarquer c’est les chainspecs qui contiennent le runtime du genesis. Il n’y a pas de sens à embarquer les versions ultérieures du runtime car elles seront récupérées à chaque runtime upgrade rencontré lors de la synchronisation.
La chose qui peut changer dans les chainspecs c’est les bootnodes. Si on veut mettre à jour les bootnodes, on publie une nouvelle version du client qui embarque les nouvelles chainspecs avec le même runtime genesis, mais des nouveaux bootnodes.
La version du runtime indiquée dans l’image actuellement c’est la version de runtime du genesis, qu’on a utilisée pour distinguer les réseaux successifs.
Et donc ça n’a pas tellement de sens d’embarquer des bootnodes pour un réseau donné (par ex gtest) mais des runtime genesis pour trois réseaux (gdev, gtest, g1).
Pour une image de dev, on n’embarque pas de genesis, mais on le crée à la volée avec un runtime natif, donc compilé directement et pas embarqué en wasm.
J’espère que je ne rajoute pas de confusion. Ça peut paraître compliqué au départ, mais il faut juste se poser au calme une bonne fois pour toutes pour comprendre et ensuite ça paraît plus simple.
Non au contraire tu remets un peu à plat, mais ce n’est toujours pas parfaitement clair de mon côté.
Dans ce cas, si la seule “variable” mouvante au grés des réseau est ce bootnode, ne serait il pas pertinent de le sortir des chainspecs dans un fichier externe, lui même gitignore, de manière à avoir des chainspecs 100% durables ?
Actuellement nos builds du client sont mono-réseau, il faudrait les passer en multi-réseau (nécessite des évolutions pour aller chercher la chain-spec de chaque réseau gdev, gtest et g1 dans la bonne release réseau)
La compatibilité avec un réseau devient implicite, ce qui est source de confusion
Exemple duniter-v2s-gtest-1100:1000-0.12.0 m’indique tout de suite que ce client est compatible avec la gtest démarrée avec le runtime 1100, et dont le runtime natif est 1000 (ce qui est une anomalie d’ailleurs, mais ça se voit) et le client est en version 0.12.0. Je suis alors sûr (du moins, sur le principe) que j’ai un client fait pour ce que je souhaite faire ou ne pas faire.
Si tu ne mets plus ces nommages, tu perds ce lien explicite. Il faut alors une table de compatiblité pour chacun puisse vérifier qu’il a bien la version attendue pour ce que tu essayes de faire. Tu me diras : même avec le nommage explicite c’est le cas actuellement, alors à quoi bon ? Oui, c’est pas faux.
Oui je pense que maintenant ce genre de table est à notre porté, que ce soit sur le readme, docs/ wiki ou poste de forum
Aussi il suffit d’ajouter un log au démarrage de Duniter indiquant tous les réseau disponibles dans ce client, puis le réseau actuellement sélectionné, voir même pourquoi pas une commande qui affiche explicitement ces réseaux.
J’ai l’intime conviction que ce sujet est entièrement lié au sujet du tag embed, dont l’implémentation doit aller au bout de la démarche pour récupérer les bon chain specs lors de la sélection du réseau.
