Salut Pini, merci d’avoir essuyé les plâtres 
on pourrait passer un peu de temps ensemble jeudi ?
3 Likes
Pourquoi pas, mais je n’ai rien fait depuis mardi soir (je viens de rentrer chez moi). Pas certain d’être prêt à partager quoi que ce soit. Anyway, je vais pousser le truc sur le gitlab histoire de donner un peu de visibilité 
En écrivant ça je constate qu’il existe déjà un Dockerfile vieux de 4 ans…
EDIT : Voilà, c’est poussé là : Files · pini-docker · pini / cesium-plus-pod · GitLab
Je m’y remets après le diner.
3 Likes
Voilà, je pense que j’ai un premier jet à peu près présentable. C’est dans cette MR.
Il me reste un point sur lequel je n’ai pas de réponse : à quoi sert le port 9300 qui n’est cité nulle part dans la doc d’installation ?
@HugoTrentesaux @Moul @aya : merci de jeter un oeil.
1 Like
au top, merci @Pini. 9300 normalement c’est un port pour la réplication entre les noeuds elastic search.
2 Likes
Il y a une chose que je ne suis pas certain de bien comprendre avec ElasticSearch : c’est la notion de cluster.
Je suis tenté de comprendre que tous les pods Cesium+ sont censés former un unique cluster. Si c’est bien le cas, alors :
- Le nom du cluster doit être le même pour tous : “cesium-plus-pod” ?
- Nos pods sont censés échanger des données via l’API Transport (port 9300). Dans ce cas quelqu’un dispose-t-il d’une configuration nginx pour gérer ce port 9300 derrière un revere-proxy ?
Merci par avance pour vos éclairages.
Salut à tous,
Déjà, merci d’avoir creuser sans aide externe. Je ne pouvais vraiment pas… la famille et la santé d’abord (qui voudra comprendra).
Du coup, @Pini , tu as résolu ton problème de sécurité ?
Est-ce que je peux merger ta MR ?
1 Like
Cette option de config permet d’ajouter des noeuds dont les données seront récupérées, indépendamment de la découverte des noeuds du réseau.
il y a en effet une autre option (duniter.p2p.discovery.enable - je l’écris de tête) qui permet d’activer la récupération automatique des autres noeuds par scan réseau (via les fiches de pairs de Duniter, sur l’API BMA /network/peering.
Mais cette récupération dépend beaucoup de la qualité des fiches de pairs (si elle sont bien publiées, et sans erreur, et sans doublon par clef).
Par exemple, si un noeud Duniter tourne sur la même clef, alors c’est à Duniter de publier les endpoints Cs+. En revanche, si le Pod est seul (sans noeud Duniter) alors il faut aussi activer la publication d’une fiche de pair, par le Pod Cs+. (il ya d’autres options pour cela).
Ceci vient du fait que Duniter considère une seule fiche de pair par clef. Il faut donc qu’elle soit complète.
On ne peut pas deviner à l’avance comment tourne le Pod Cs+ (seul ou couplé avec un noeud Duniter)
Je ne sais pas si je suis très clair ? 
2 Likes
@kimamila je pense que si tu pouvais me consacrer 1/2h en audio un de ces soirs ce serait plus simple. Qu’en penses-tu ?
1 Like
Le soir c’est plutot compliqué. En journée après 14h ?
1 Like
Salut, mon pod adn life est fonctionnel mais également en retard de documents… peux-tu me dire ce que tu as modifié exactement pour qu’il récupère la synchronisation des documents ?
Amicalement, Francis
Salut, voici le contenu de mon endpoints :
duniter.p2p.includes.endpoints: [
"ES_CORE_API g1.data.le-sou.org 443",
"ES_USER_API g1.data.le-sou.org 443",
"ES_SUBSCRIPTION_API g1.data.le-sou.org 443",
"ES_CORE_API g1.data.e-is.pro 443",
"ES_USER_API g1.data.e-is.pro 443",
"ES_SUBSCRIPTION_API g1.data.e-is.pro 443",
"ES_CORE_API g1.data.adn.life 443",
"ES_USER_API g1.data.adn.life 443",
"ES_SUBSCRIPTION_API g1.data.adn.life 443"
]
Tu coup pour toi ça serai plutôt ça :
duniter.p2p.includes.endpoints: [
"ES_CORE_API g1.data.le-sou.org 443",
"ES_USER_API g1.data.le-sou.org 443",
"ES_SUBSCRIPTION_API g1.data.le-sou.org 443",
"ES_CORE_API g1.data.e-is.pro 443",
"ES_USER_API g1.data.e-is.pro 443",
"ES_SUBSCRIPTION_API g1.data.e-is.pro 443",
"ES_CORE_API g1.data.mithril.re 443",
"ES_USER_API g1.data.mithril.re 443",
"ES_SUBSCRIPTION_API g1.data.mithril.re 443"
]
1 Like
OK, merci j’ai compris Par contre je ne sais pas comment mettre à jours mon pod vers 1.9… mais bon déjà si j’arrive à récupérer le bon nombre de documents, ça sera pas mal.
Alors moi je fais comme ça :
- je télécharge le zip de la nouvelle version que je mets dans le dossier home de mon utilisateur cesium
- je le décompresse
- je coupe mon pod actuel
- je fais une copie du dossier data et du fichier elasticsearch
par exemple si tu vas de la version 1.6.5 à la version 1.9.1 ça donnera quelque chose comme ça :
cp -R cesium-plus-pod-1.6.5/data/ cesium-plus-pod-1.9.1/
cp cesium-plus-pod-1.6.5/config/elasticsearch.yml cesium-plus-pod-1.9.1/config/
- puis je démarre mon nouveau pod :
cesium-plus-pod-1.9.1/bin/cesium-plus-pod start
1 Like
Merci, je vais essayer ça
1 Like
Je viens de mettre en ligne g1.data.pini.fr créé sur la base de cette MR.
C’est en train de synchroniser, mais je doute que ce soit parfaitement fonctionnel en l’état. Au moins ça permettra de voir ce qui marche et ce qui ne marche pas.
EDIT: L’image Docker correspondante est pinidh/cesium-plus-pod:latest.
3 Likes
Après des heures de synchro, mon instance n’arrête pas de planter avec des erreurs de ce type :
RemoteTransportException[[node][172.18.0.5:9300][indices:data/read/search[phase/query]]]; nested: QueryPhaseExecutionException[Result window is too large, from + size must be less than or equal to: [10000] but was [10500]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level parameter.];
Ça ressemble à une erreur mémoire. Est-ce qu’il y a un élément de config que je pourrais adapter pour éviter ça ?
Connaissant un peu elastic search, c’est plutôt une erreur de requête illégale. on ne peut pas réclamer 10500 résultats sur une seule requête. Car la limite fixée est 10000 résultats.
Result window is too large, from + size must be less than or equal to: [10000] but was [10500]
C’est donc un client (Cesium ? ou un autre pod, ou une autre app qui utilise ton serveur ) qui fait une requête illégale.
Le message d’erreur invite à se documenter sur l’API scroll de ES pour paginer les grosses requêtes :
See the scroll api for a more efficient way to request large data sets.
Mais on peut augmenter la limite de résultats dans la config :
This limit can be set by changing the [index.max_result_window] index level parameter.];
Bon courage !
3 Likes
J’ai passé le paramètre à 20000 ça a l’air plus stable. Merci !
Bon, j’ai donc maintenant un noeud Cesium+ : g1.data.pini.fr
Ça a l’air de marcher, mais pas avec mon noeud mirroir.
Quand je le configure dans l’extension Cesium de Firefox avec :
- Noeud de données Cesium+ : g1.data.pini.fr
- Noeud Duniter : g1.duniter.org
Ça marche.
Mais avec :
- Noeud de données Cesium+ : g1.data.pini.fr
- Noeud Duniter : duniter.pini.fr
La plupart des pages restent bloquées sur “Cesium interroge le noeud Duniter”. Je ne vois absolument aucun message correspondant (timeout, échec de connexion, …) dans les logs.
Est-ce que ça pourrait avoir un lien avec la version du noeud ? Genre incompatibilité avec les noeuds 1.9 ? Un peu d’aide serait appréciable
2 Likes
Je pense qu’il faut qu’on s’empare du code métier de Cesium, notamment pour ce genre de message, qu’est-ce que fait Cesium pendant ce temps là, temps pendant lequel on ne peut pas fermer la popup sur-imprimé évidemment…
Ca va dans le sens du hackaton Cesium que nous aimerions organiser avec @aya
3 Likes