J’ai réfléchi à cette idée de fusion des pod Cs+/Gchange. Je ne penses toujours pas que cela soit une bonne idée.
Je crois comprendre que le désir vient surtout de @poka (et @Frederic_Renault) de facilité les signatures d’annonces, en utilisant un compte portefeuille G1. @poka m’a indiqué qu’il voulait bien conserver des clients distincts, et non pas avoir un même client mobile qui gère à la fois les portefeuilles et les annonces. Ca me parait important à rappeller.
Donc, si le besoin de faire signer les annonces par un compte sécurisé. Pourquoi ne pas utiliser des G1lien (june://) sur mobile pour que la signature dans l’app gchange soit déléguée à une App de signature (Gecko par exemple). Si tel est le cas, plus besoin de changer quoi que ce soit dans l’architecture actuelle.
Peut-être que @poka pourrait mieux m’expliquer le besoin de cette fusion, ou me dire dans quel post cela a été décrit, le cas échéant. J’ai peut-être mal compris.
J’ai été plusieurs fois mal à l’aise, hier, quand il a été question de « faire vite », de « centraliser tout sur un pod » pour que ca marche, etc. Cette démarche et cette précipitation ne me plaise gère.
Des solutions ont même été évoqué de forcer des synchro de MemPool pour contourner les problèmes actuel de paiements qui ne passe pas, mais sans que ces solutions ne considère même les forks… pourtant un des points essentiels à la faiblesse des paiements aujourd’hui.
Bref, je ne penses pas être le seul à avoir ressenti cela. je me trompe ?
@kimamila J’ai déplacé ton message dans un autre sujet pour débattre. Ceci afin de ne pas polluer le fil des compte-rendus qui doit contenir uniquement des comptes-rendus.
Je ne connais pas assez le sujet pour me prononcer, mais je constate comme toi que la volonté de fusion part avec une méconnaissance de l’architecture du logiciel (Pod gchange == Pod Cesium+ avec un plugin supplémentaire). Au final, j’ai eu l’impression que la montagne accouchait d’une souris et que le sujet n’en était plus un. Il a ensuite dévié sur la sécurité des authentifications gchange.
Ce qui me gêne surtout c’est la deadline que tu te fixes @poka. Ce n’est pas à l’éco-système de s’adapter à tes délais ni à ton client en particulier. Chaque amélioration de serveur doit se faire en aillant une vision complète et globale de l’éco-système.
Le mieux est de formaliser ton besoin pour Gecko et ensuite de voir les points faibles à améliorer dans l’éco-système pour que cela profite à tous.
Pour Tikka, pas de sortie prévue avant d’avoir une assurance que le p2p est assuré. Quand je serai sur le problème des transactions, je solliciterai tous les intervenants pour réfléchir à une solution la plus élégante, la plus simple et la plus pérenne.
Pour la gouvernance des projets, il est important de bien identifier qui porte le projet et en est le mainteneur. Les développements qui modifient en profondeur un projet ne peuvent se faire sans l’accord du mainteneur. Sinon, cela devient un fork « hostile » et pas des MR classiques, validées par le mainteneur comme il se doit.
C’est pour cela que le hackathon, pour chaque projet, doit se faire avec la participation ou à minima l’accord explicite du mainteneur. C’est ce qui se passe avec Elois et Duniter/GVA, et cela doit être identique avec Kimamila et Gchange/Cesium.
Certains points abordés en réunion sont de « gros » sujets qui nécessitent vraiment une réflexion de groupe et des propositions diverses avant de taper la première ligne de code.
D’après ce que j’ai compris de ElasticSearch, il existe un système de réplication qui permet de se baser sur une architecture fédérée (@kimamila j’ai bon? mais j’arrive pas à l’activer)
Ce qui me parait important, c’est l’expérience utilisateur. Et depuis un moment déjà, le fait de mettre des noeuds fixés par défaut dans les appli Cesium/Gchange “centralise” les requêtes vers les mêmes machines qui saturent… On devrait avoir des “bootstrap” qui redirigent les clients en “load balancing” vers les autres noeuds. Pourquoi cela n’est pas possible?
Pour ma part j’utilise Gchange+ (et ses étoiles) pour maintenir la connexion d’essaims IPFS liés aux comptes (qui sont en même temps identités et portefeuilles, c’est dans le design! L’usage de clefs ed25519 relie tous les logiciels qui l’utilisent, on ne peut pas faire autrement). On obtient une architecture N+1 / N+2 (anoptique) semblable à ScuttleButt comme ça. Avec la nuance des étoiles en plus
Pour continuer, j’aimerai utiliser mon propre noeud GPod pour éviter de saturer l’unique en ligne.
Mais je n’arrive pas à rejoindre la fédération ES…
Je fais une visio demain à 15h pour ceux que ça peut intéresser
Je suis content d’enfin avoir des réactions éclairés face à cette proposition
Bien noté, je vais donc essayer d’argumenter cette proposition, car je vois dans la suite des messages qu’il manque certains éléments de motivations.
Autant vous dire tout de suite qu’il ne sera rien si @kimamila à minima ne valide pas la proposition, cela me semble évident. MAIS seulement si ce désaccord est construit et motivé, comme tu as commencé à le faire
Alors je te remercie de te soucier si j’ai bien compris l’architecture logiciel de notre écosystème, mais je pense avoir assez bien capté justement que les pods gchange sont des pods Cs+ avec plugin oui
Bon alors je reprends depuis le début mon raisonnement du pourquoi cette fusion.
D’abords ce n’est pas du tout lié à Gecko. Je songeais à cela l’été dernier déjà, lorsque j’ai commencé à faire Jaklis.
L’origine de cette réflexion, c’est avant tout pour répondre à cette question :
“Pourquoi ne pas utiliser les mêmes logins et profiles pour Cs+ et gchange.”
Voici donc pour résumer mon raisonnement:
Pour les logins il faut faire comme pour ce qui a été fait pour cesium web, restreindre les login en web, mais bien réfléchir aux appels à actions pour que le switch vers l’app local se fasse de manière la plus transparente possible
Pour les profiles, étant donné que les pods gchange sont en réalité des pods Cs+ avec des champs en plus avec l’API /market correspondante, alors pourquoi ne pas tout simplement utiliser les mêmes pods pour l’un et l’autre, dans la mesure ou nous cherchons justement à avoir les mêmes profiles en préambule !
Et enfin voici une liste non exhaustive de ce que cette solution apporterait selon moi:
Une bien meilleure clarification de comment fonctionne notre écosystème pour les utilisateurs
Bien plus simple de ne créer qu’un seul login/profile pour les 2 outils pour l’utilisateur
Une maintenance de ces nœuds simplifié, car il s’agit de propager juste un type de nœud, où chaque admin pourra choisir d’activier/désactiver les fonctions gchange et autre, car tout ceci est déjà développé sous forme de plugin sur ces pods
Moins de support car 1 seul type de nœud, et moins de confusion auprès des utilisateurs.
Oui absolument ! Je n’ai jamais parlé de fusionner les clients, surtout pas !
J’ai bien précisé à chaque fois que je ne parle que des pods, le backoffice.
Avoir séparé le front de gchange de Cesium était exactement ce qu’il fallait faire, cependant la séparation des backsoffices ne me semble désormais plus nécessaire dans la mesure où l’on décide d’effectivement de rendre gchange.fr en lecture seule.
On peut tout à fait, mais cela n’est pas du tout incompatible avec la fusion des pods et profiles, pour toutes les raisons que j’ai évoqué plus haut.
Mais évidemment qu’il ne s’agit pas d’imposer quoi que ce soit ni de faire vite et mal !!
Moi ce que je propose, c’est de faire vite et bien lol
Non plus sérieusement, j’ai pas parlé de deadline pour ce projet, juste de hackaton, qui lui est daté.
Pendant ce hackaton je propose simplement de passer 1 journée complète sur des changements à effectuer sur les pods Cs+ et gchange. Si on décide pour x raison de ne pas les fusionner, c’est pas grave, on sait déjà qu’il y a d’autres choses à faire au sujet de ces nœuds, pas vrai @kimamila ?
J’ai jamais parlé de forker quoi que ce soit non plus hein. Juste de créer des branches, tester, faire tester, faire approuver, et faire une/des MR(s).
Perso l’idée d’avoir un seul profil me plaît bien, car actuellement j’ai un profil sur césium+ et un autre sur gchange.
Pour le reste je laisse faire les pros !
@kimamila et @vit je me permets de vous relancer sur ce sujet, pour avoir vos remarques par rapport à ma réponse, et votre avis général face à cette fusion.
Pensez-vous que c’est une bonne idée ?
Est-ce qu’on maintient le hackaton là-dessus ?
Si non, j’ai proposé de remplacer cet atelier par un atelier « Implémenter les QRCode d’annonce sur les pages d’annonce du client GChange »
(voir RFC de @tuxmain à ce sujet)
Cet atelier me semble plus simple encore que la fusion des Pods, car cette dernière nécessite plusieurs étapes très différentes côté GChange Pod, Cs client et Gchange client, alors que l’implémentation des QRCode ne requière que de toucher à une vue du client GChange (en reprenant exemple sur le code métier qui fait ça pour les clés publiques côté Cs).
L’idée de faire ça en hackaton, c’est de nous inciter à entrer dans le code de ces outils ensemble, pour y devenir contributeur au fur et à mesure.
Dans les 2 cas, j’aimerais avoir le feu vert de @kimamila là-dessus, et dans les 2 cas, je me sens capable d’animer l’un ou l’autre de ces ateliers, dans la mesure où j’aurais pris une journée complète auparavant pour le préparer (branches de dev, environnement de dev local ok, et quelques questions à poser à Benoit encore pour préparer ce dev).
@kimamila seras-tu dispo en remote pendant cet Atelier Lundi 29 Mars ?
Et est-ce qu’on peut se refaire un call la semaine du 22 lorsque j’aurais commencé à préparer l’atelier validé (installation de l’environnement de dev, compréhension général de la conf, création de la branche sur les dépots git de gchange-pod, gchange-client et cs-desktop) ?
Je ne me sens pas légitime à me prononcer sur le sujet. C’est à @kimamila de le faire. Peut-être que son hésitation à y voir un bénéfice vient du fait qu’il a séparé les deux au départ. Il faut lister les avantages et les inconvénients, et essayer d’imaginer les effets de bord (le plus dur…).
Bref, quelque soit la décision, elle sera bonne… Jusqu’à ce qu’on fasse autrement.
Contrairement à ce qu’a dit vit, mon accord n’est pas obligatoire pour faire ce que vous voulez avec le code. C’est libre
Je persiste à dire que si les clients sont différents, alors on n’a pas besoin d’avoir les même Pod.
Les trousseaux sont indépendants donc peuvent très bien servir au deux réseaux, tout comme ils peuvent servir à faire du SSH, ou SSB etc.
Par ailleurs, petit nuance que j’ajoute : gchange Pod sait faire du multi-monnaie. C’est à dire qu’on pourrait avoir des annonces sur une G2. On voit alors que les besoins d’indexation de monnaie différents.
Enfin, si on veut des bonnes perfs sur les clients gchange, on n’a pas intérêt à ce que les Pod indexent toute la BC comme le fait Cs+ (les Pod gchange sont configurés pour n’indexer que les événements BC qui concerne gchange).
Bon je vois que tu parles toujours uniquement des trousseaux mais pas des profiles utilisateurs, alors qu’a j’ai quand assez bien insisté là dessus…
Je n’y vois rien de contradictoire, changer de datapod fait changer de monnaie et d’annonce, logique même !
On vends un objet dans une monnaie, pas dans plusieurs monnaies.
Et enfin, il est évident qu’il est hors de question d’indexer la blockchain comme le fait Cs+ !
Merci de rappeler ce point j’ai oublié de le préciser sur mon précédent poste: La partie indexation blockchain de Cs+ n’a pas lieu d’être sur ce g1-datapod, c’est un tout autre sujet.
Bon je ne voit n’y enthousiasme ni refus catégorique face à cette proposition, j’ai donc envie de maintenir ce hackaton pour essayer cela, à condition qu’au moins 1 dev soit avec moi sur LiveShare pour se faire
oui, il faut essayer, aussi pour voir les limites.
Du coup si tu n’indexe pas la BC, alors le g1-datapod ne peut pas servir à Cesium+ (notifications, etc.), ni à gchange (indexation pour les TX de crowdfunding).
Du coup pourquoi ne pas l’appeler gecko-pod ? ou autre. Il faut une clarification de nom, à mon avis.
Je penses qu’il te faudra vraiment détailler chaque fonctionnalité à utiliser.
Tu pourrais très bien, aussi, y synchroniser tous les profiles, d’une autre manière que la mienne.
Bah non justement c’est que je ne veux pas recréer un gecko-pod+, le but c’est justement de mutualiser ces pods pour différents outils, de ne plus les rendre spécifiques à Cesium et gchange uniquement, mais que par exemple demain 2 devs décident de créer un blablaJune (covoit g1), bah qu’ils utilisent g1-datapod pour leur backoffice, en ajoutant simplement les champs spécifiques pour leur outil. Et ce pour tous type d’outil g1 en fait.
Ca reste un choix de faire son propre backoffice seul dans son coin, mais ça devient possible de mutualiser sur un back pensé pour ça quoi.
Je pense que ça pourra faciliter le dev d’autres outils g1, et motiver des dev à se lancer (ce n’est que m’on point de vue)
Dans tous les cas, il ne peut être que bénéfique de mutualiser au max nos outils.
Oui tu as raisons, en fait, une bonne partie de ce chantier que je n’avais pas forcément exprimé, va être de réfléchir à comment séparer tout ça, mais je suppose que les fonctions d’indexations sont déjà intégrés sous forme de plugins non ?
C’est pour ce genre de questions que je voudrais faire un autre call avec toi, mais seulement une fois que j’aurais installé tt l’environnement de dev et commencé à mettre les mains là dedans, ce qui n’est pas vraiment encore le cas.
Là à chaud, je ne sais pas si les g1-datapod devraient avoir un plugin d’indexation cs-blockchain et un plugin gchange-CF, ou bien si il faut fusionner ces 2 fonctions d’indexation dans un nouveau type de pod, genre g1-index, qui seraient principalement utilisés par Cs et gchange, mais là honnêtement je n’ai pas d’idée précise et 100% satisfaisante là dessus.
Je pense qu’il faut qu’on axe le débat autour de ce point précis désormais, ça me semble le plus bloquant en effet.
Il est hors de question de faire quoi que ce soit avant que cette question soit tranché, et bien entendu hors de question que ça impact négativement les clients Cs et gchange, ni que ça complexifie l’architecture, le but est quand même au contraire de simplifier cela, c’est ce que je m’efforce de faire.
Et pour revenir sur ta remarque de plutôt faire mon back dans mon coi pour gecko spécifiquement, sache que dans Gecko une part importante du dev que je fais est justement de permettre l’import de portefeuilles Cesium en plus de la nouvelle mécanique fait pour Gecko, donc je prends énormément en compte l’existant contrairement à ce que tu pourrais penser.
@kimamila est-il possible de lancer son noeud cs+ sans le plugin cesium-plus-pod-core ?
Question 2: Est-il possible d’ajouter le plugin gchange-pod à mon noeud Cs+ local (mode dev compilé) sans à refaire l’install de zero pour gchange pod ?
Je précise qu’un test unitaire échoue chez moi depuis le début, mais ne semble pas bloquant pour le fonctionnement général du pod:
Results :
Tests in error:
deserialize(org.duniter.elasticsearch.model.SearchScrollResponseTest): Délai d'attente de la requête dépassé
savePeers(org.duniter.elasticsearch.service.PeerServiceTest)
Tests run: 6, Failures: 0, Errors: 2, Skipped: 3
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Cesium+ pod 1.7.1-SNAPSHOT:
[INFO]
[INFO] Cesium+ pod ........................................ SUCCESS [ 0.223 s]
[INFO] Cesium+ pod :: Test utilities ...................... SUCCESS [ 0.509 s]
[INFO] Cesium+ pod :: Core plugin ......................... FAILURE [ 39.502 s]
[INFO] Cesium+ pod :: User plugin ......................... SKIPPED
[INFO] Cesium+ pod :: Subscription plugin ................. SKIPPED
[INFO] Cesium+ pod :: Assembly ............................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 40.441 s
[INFO] Finished at: 2021-03-15T13:56:35+01:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test (default-test) on project cesium-plus-pod-core: There are test failures.
[ERROR]
[ERROR] Please refer to /home/poka/dev/cesium-plus-pod/cesium-plus-pod-core/target/surefire-reports for the individual test results.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <args> -rf :cesium-plus-pod-core
Bon ce sera plus simple de vive voix, par écrit les aller retour vont être nombreux sinon je pense ^^ (jsuis un peu lent des fois)
Il faut essayer, et voir si les autres plugins démarrent, si des foncitonnalités ou index te manquent, etc. Je ne sais pas te dire, comme ca de tête, les impacts.
Tu peux :
modifier le fichier de config suivant à ta guise : cesium-plus-pod-assembly/src/test/es-home/config/elasticsearch.yml
Puis compiler avec mvn install -DskipTests :
normalement dans le répertoire cesium-plus-pod-assembly/target/es-run-home tu as une installation prête à démarrer, dans laquelle tu peux ajouter le plugin gchange-pod-plugin.
Il te restera plus qu’à lancer le pod, avec la commande : . ./bin/elasticseach
ASTUCES :
Tu peux aussi faire une compilation ET lancement, en ajoutant Prun (pour activer le profile Maven run)
Et si tu veux garder tes données à chaque compilation + lancement, tu peux ajouter l’option -Dassembly.skip qui évite de re-créer le répertoire es-run-home
Merci je vais essayer de me repencher sur ces pods cette semaine du coup
Je confirme tout ce que j’ai dit ici, et je rajouterai juste que:
Je ne dis pas que l’indexation BC n’a pas ça place du tout dans les g1-datapods, mais juste que ça doit être découplé du coeur pour être juste optionnel (pas besoin de duniter si pas d’indexation donc infiniment plus léger à installer et déployer). Faut juste pour désactiver le plugin quoi c tout. Pas besoin de centaines de noeud d’index ES, alors que besoin de redonder les données utilisateurs, et faciliter l’install de noeud avec données de profiles spécifiques (blablajune, rbnJune, ectect)
Concernant Cesium V2, je voudrais bien avoir ton commentaire au sujet de l’indexation des pods Cs+.
Penses-tu que avec GVA + indexations spécifiques nécessaires côté Duniter, certains index seront encore nécessaire sur ces pods Cs+ ?
Pour l’index liés aux crowdfunding gchange, tu peux en dire plus ? Besoin de Duniter local pour ces index ? Ca n’a rien à voir avec les index BC en fait si ? Comment c’est couplé ?
Laissons ceux qui font ces services (où sont ils donc ?) dire leur besoin.
Les optimisations ont pourra les faire ensuite, si besoin.
C’est plus facile d’enlever que d’ajouter
Cela dépend des performances de l’API, mais aussi des la roadmap de Duniter.
Mon but est de jamais être bloqué si les dev du coeur disent qu’un truc n’est pas prioritaire, ou pas lié au noeud, etc. et aussi d’avoir une API générique d’accès à … toute la BC, ET avec des fonctions d’agrégation (sum, avg, etc) et de filtrage
Dans tous les cas, l’index user/event est par exemple hyper utile, et optimisé :
pour suivre l’avancement du crowdfunding, gchange-pod utilise cesium-plus-core pour trier les TX, et remplir /g1/movement qui indexe les mouvements de comptes (une TX peut avoir plusieurs mouvements).
