Urgent : problèmes majeurs pour les utilisateurs

[aya]

@kimamila

Je ne suis pas certain de la configuration d’avant, mais je penses qu’il y avait un nœud de l’infra Duniter. Sans doute géré par Ansible. cc @moul @cgeek une idée ?

En effet c’est bien dans ansible et il y a bien un noeud local.

Sign in · GitLab

@Moul il suffirait de retirer les lignes 141 à 156 ?

[immae]

@aya

@Moul il suffirait de retirer les lignes 141 à 156 ?

C’est un peu plus compliqué que cela mais si c’est le choix je peux m’en charger

[Moul]

@immae

Je veux bien supprimer le load balancer, mais par quoi faut-il le remplacer ?
Est-ce qu’il faut uniquement servir le nœud local ?
Est-ce qu’on prévoit de remettre le load balancer à un moment et je le remplace juste par un load balancer à un seul nœud le temps que les autres soient mis à jour ?
Je peux aussi ajouter une “règle” de sanity qui vérifie la version actuelle pour déterminer si un nœud est “utilisable” (et ainsi chacun peut mettre à jour son nœud à son rythme.

@immae

Si vous me dites que le LB n’a plus lieu d’être je le supprime, il faut juste me dire par quoi je dois le remplacer .
Ou plus précisément: vers quoi dois-je faire pointer le nœud en g1.duniter.org une fois que j’aurai supprimé le LB ?

Il s’agit de répondre à ces questions. Savoir ce qu’on fait avant de le faire. Qu’est-ce que l’on veut comme résultat ?

Je trouvais le LB pas très malin, car tu te retrouves avec des vues différentes dans le cas de piscines différentes entre autres problèmes. Il a été mis en place en première place pour parer à la lenteur de clients BMA qui n’était plus acceptable pour l’expérience utilisateur.

Si les problèmes de lenteurs sont rendus raisonnables avec Duniter v1.8.7, on pourrait supprimer le LB et le faire pointer vers le nœud local g1.duniter.fr. Préalablement, ce nœud doit être mis en v1.8.7 afin de bénéficier des performances qu’elle offre.

Qu’en pensez-vous ?

[aya]

Je pense que c’est exactement ce qu’il faut faire

[immae]

Très bien, donc on veut rediriger vers le nœud local (sur redshift). Actuellement ce nœud est en 1.8.5. Est-ce que du coup j’attends avant de modifier ?

Actuellement, il y a trois nœuds up sur 6 :

• redshift, 1.8.5
• vit.fdn.org, 1.8.7
• g1.e-is.pro, version inconnue (je ne peux pas faire une requête sur / )

Si c’est urgent (d’après le sujet), est-ce que je dirige vers vit.fdn.org en attendant que redshift soit mis à jour ? Je peux essayer de m’occuper de ladite mise à jour mais n’étant pas à l’aise avec les nœuds je préférerais que quelqu’un d’autre le fasse (c’est un container docker, il suffit peut être de faire un git pull et relancer ? Je peux tenter mais si je me plante il ne reste plus que deux nœuds).

[Moul]

• https://g1.e-is.pro/node/summary est en v1.8.7

g1.duniter.fr est dans Docker, il faut mettre à jour l’image puis faire une nouvelle synchronisation. Ici en particulier pour ce changement de version qui comporte un changement du schéma de la bdd.

Voici la documentation concernant l’installation avec Docker : https://forum.duniter.org/t/g1-node-installation-maj-resync/7376

Les autres endpoints devraient prendre le relais via le LB vis-à-vis de ce nœud down le temps de là màj et de la nouvelle synchro.

[cgeek]

La mise à jour du nœud va mal se passer, Duniter 1.8.7 affiche un bug de migration au redémarrage.

[kimamila]

Je penses qu’on peut prendre le temps de migrer correctement le redshift, et rediriger le LB vers un des deux noeuds 1.8.7

Dès que le noeud aura été migré, on pourra pointer dessus.

Oui désolé @cgeek j’ai du mal comprendre un truc pour la migration de la BDD… Il faut un reset data.

@Moul

Je trouvais le LB pas très malin, car tu te retrouves avec des vues différentes dans le cas de piscines différentes entre autres problèmes. Il a été mis en place en première place pour parer à la lenteur de clients BMA qui n’était plus acceptable pour l’expérience utilisateur.

Pas très malin oui, surtout qu’en fait les lenteurs venaient des noeuds eux-mêmes. En fait on s’est rajouté des problèmes… On a réparti des requêtes lentes, certes, sur plusieurs machines, mais on a créé des incohérences côté client…

D’ailleurs j’avais largement prévu de tous ces soucis potentiels, comme d’ailleurs sur le fait que choisir un noeud au hasard dans Césium allait nous poser d’autres problèmes, et que c’était loin d’être un problème simple.
On est en plein dedans avec g1v1.p2p.legal ! Je l’ai mis dans la liste des noeuds tirés au sort pour lire le réseau… Sauf qu’aujourd’hui il ne connait plus aucun autre noeud. Du Césium penses qu’il est sur la branche principale, et le conserve ! Beaucoup d’utilisateurs sont bloqués sur ce noeud.

Pfff, moi qui pensait être tranquille au mois d’août. Raté !

Merci de votre aide les zamis !

[vit]

Ouah, c’est chaud ! Quelle responsabilité (humour).

Pour info, mon nœud vit.fdn.org est un nœud auto-hébergé et je subis de temps en temps des coupures de courant.

Mais je veux bien être vigilant le temps de migrer redshift, et relancer mon nœud asap si problème.

[kimamila]

SInon @cgeek ton noeud g1.cgeek.fr est bien joignable en HTTPS, mais ton /network/peering retourne :

  "endpoints": [
    "BASIC_MERKLED_API g1.cgeek.fr 35556",
    "WS2P b58ff577 82.65.206.220 20900"
  ],

• il manque le endpoint BMAS dans ta config
• l’accès BMA sur 35556 ne fonctionne pas
  (je n’ai pas essayé l’accès ws2p)

[kimamila]

@vit

Pour info, mon nœud vit.fdn.org est un nœud auto-hébergé et je subis de temps en temps des coupures de courant.

Ton noeud est Down où c’est chez moi qu’il y a un pb ?
Tu as des règles FW particulière ? genre ban IP ?

[flodef]

@kimamila

Ton noeud est Down où c’est chez moi qu’il y a un pb ?

Noeud down, en effet !

[cgeek]

@kimamila

il manque le endpoint BMAS dans ta config

Merci, je viens de le rajouter.

@kimamila

l’accès BMA sur 35556 ne fonctionne pas

http://g1.cgeek.fr:35556/ fonctionne bien chez moi, il faut ouvrir une fenêtre de navigation privée par contre.

En tout cas mon nœud (1.8.7) est bien stable, sur un bon serveur, fibré, dispose d’un gros onduleur et est monitoré par mes soins. Donc je dirais que c’est un nœud fiable, sur lequel on peut se reposer @immae. Dès maintenant.

[immae]

Noté. Si pas d’objection d’ici cette nuit (~23h-minuit) je change la config pour faire pointer g1.duniter.org vers ce nœud (“g1.cgeek.fr:35556/”) uniquement.

[kimamila]

oui, super. Ca me semble parfait !

[vit]

https://vit.fdn.org:10900/

est UP.

Il ne faut pas se fier au dsn incomplet que Discourse rend cliquable mais qui vous amène sur une impasse car il manque le port (sauce aigre douce).

[immae]

Voilà la MR (déjà appliquée) pour le changement du proxy :
https://git.duniter.org/admins/duniter-infra/-/merge_requests/54

[cgeek]

Merci, https://g1.duniter.org/network/peering pointe bien sur mon nœud mais je ne vois pas ni dans la MR ni dans duniter-infra comment tu réalises le proxy-pass

[Moul]

La variable upstream_server a surement été passé en argument.

[immae]

Non, tu as raison. J’ai fait un rebase qui a provoqué un conflit et j’ai complètement foiré la résolution du conflit.
Je règle ça