Tout le monde peut l’avoir ca j’ai aucun doute la dessus et c’est meme normal. Par contre de la a savoir pourquoi…
Lorsqu’on fait : Gestion des plugins > Market
3 possibilités :
-time out
-réponse vide
-accès pages plugin mais très lent
Peut-être comparer l’API market et le JSON RPC avant et après le 08/12.
akenad 
Pas de changement la dessus tu te doutes bien que c’est la 1er chose que j’ai faite… La maintenance c’était :
- passage de kubernetes en 1.16
- passage de traefik à nginx
- passage sur les nouveau load balancer OVH
- ajout d’un noeud de calcul
On peut eliminer le dernier mais les autres… J’ai demandé a OVH de regarder leur load balancer.
Je ne vois pas encore de raison à cela mais depuis ce matin je test régulièrement et j’ai systématiquement l’erreur sur un debian buster et (plus) jamais (depuis que j’ai fait apt upgrade) sur mes stretch (3 différents: un pi raspian en 9.9, deux vm debian 9.13, une smart en 9.4).
Ce genre de tests empirique je m’en méfie généralement mais là depuis ce matin c’est le cas, la coïncidence commence à être douteuse…
OVH a vu un soucis sur un des noeuds du cluster kubernetes j’ai forcé le noeud à rebooter pour voir si ca corrige. C’est pas toujours super rapide mais j’ai plus d’erreur maintenant.
la répartition du trafic est en effet une piste intéressante.
à corréler peut-être avec la mise en oeuvre de :
-https
-http2
-le mode de répartition du trafic (round-robin, least connection, shorted expected delay, etc …)
-le nombre de sessions/connexions maximum
Maintenant sur plusieurs tentatives certaines répondent bien et d’autres non.
Donc au contraire, si c’était moi je retirerais le nouveau noeud du pool pour voir si ce n’est pas lui qui pose problème.
akenad
En faite non le soucis est encore la OVH regarde apparement on est plusieurs dans ce cas la.
Il cherche en tout cas le soucis semble pas etre un probleme de configuration coté jeedom mais coté OVH
tout à fait
akenad
On va attendre le retour d’ovh en tout cas je tiens a salué leur professionnalisme j’ai toujours eu une réponse rapide avec une vrai analyse derrière. Si ils nous lisent merci
2 « J'aime »
ce que je voulais dire, c’est que probablement, c’est pas le nouveau noeud en lui-même qui a un problème,
mais la manière dont il est configuré dans le cluster ou la répartition de charge.
un truc à essayer c’est de le retirer.
akenad
Le soucis est identifiié ya un noeud qui repond pas LAYER 4 timeout de temps en temps et c’est pas le nouveau… OVH regarde ya une difference sur le kernel juste sur ce noeud la justement
2 « J'aime »
c’est quel service qui assure la terminaison SSL ?
akenad
Un proxy nginx
en amont du LB ?
akenad
Après le lb va fait :
LB → nginx (qui fait la partie ssl) → worker
donc la répartition se fait sur du https.
akenad
C’est un peu plus compliqué ya 2 LB qui envoi sur 4 nginx qui envoi eux sur 4 ou 6 worker suivant le service
Ouah, toutes ces réponses!! Merci à tous pour le retour et pour le travail effectué, la ça me dépasse un peux lol. Je vais attendre patiemment la résolution du problème par les équipes. Merci à tous.