Draft: Fix wikigen errors due to sites in installation process

This merge request fix the errors we could get in the CI due to sites we are currently installing.

Because theses sites have incomplete description, we don't want them to appear in the wiki.

This merge request modify the rake gen:wiki generators so that they will ignore sites that have the production property to false.

assigned to @pijacquo

Je ne suis pas sur que ça soit la meilleur façon de faire ton implémentation car pour chaque tache rake (générateur), tu peux déjà rajouter le site en paramètre (SITE=XXXX).

C'est donc un peu étrange le 'next_if', car

• 1/ tu as déjà une logique de choix de site dans le lancement de chaque commande rake
• 2/ là tu autorises avec les 'next if' certains générateurs sur 'strasbourg' et tu enlèves 'strasbourg' d'autres générateurs. J'ai l'impression que ca implémente un cas temporaire hyper particulier.

Je me demande si :

• il ne faudrait pas plutôt enlever 'Strasbourg' des site dans le Rakefile :

https://gitlab.inria.fr/grid5000/reference-repository/-/blob/master/Rakefile#L22

G5K_SITES = RefRepo::Utils::get_sites - ['strasbourg']

• et considérer que pour un site en cours d'installation, il faut lancer chaque générateur spécifiquement pour ce site avec la variable SITE=strasbourg

Ou alors avoir une variable globale dans la tache rake qui permet de configurer pour chaque générateur d'ignorer ou non un site.

Certes, on peut choisir le site sur lequel on fait tourner le rake.

Le problème, c'est que certaines page wiki se référencent les unes les autres, comme c'est le cas des pages hardware de site. Elle contiennent chacune un raccourci vers toutes les autres pages. Si on laisse faire le script, il va notamment pointer vers des pages de strasbourg qui n'existent pas encore. (Personnellement ça ne me dérange pas, mais lorsqu'on a commencé l'installation de Toulouse, on avait choisi de ne pas laisser apparaître les pages de Toulouse qui contennaient des informations non valides concernant le cluster montcalm).

EDIT: en plus, la page environment est générée en requêtant l'api de chacun des sites. Vu que celle de Strasbourg n'existe pas encore, la génération de la page plante

Je ne comprends pas pourquoi tu dis que j'enlève strasbourg d'autres générateurs et que je l'ajoute pour d'autres. Actuellement, les tâches rake concernant le wiki sont un peu trop zelées, et génèrent de la doc pour le site de Strasbourg. Comme cela déclenche des erreurs dans la CI, je veux juste ne pas générer cette doc tant qu'elle n'est pas un minimum correcte.

Pour ce qui concerne l'utilisation de la variable G5K_SITES j'ai peur qu'enlever strasbourg de cette variable nous empêche de générer les fichiers de configuration lié au site aussi. Je n'ai pas encore vérifié, alors il est possible que ce que je dise soit faux, mais cette variable m'a l'air d'être très globale dans le Rakefile, et de ne pas concerner uniquement la génération du wiki.

Quel est le problème qu'on cherche à résoudre, exactement ? Si le site est en cours d'installation, c'est normal d'avoir des erreurs CI le concernant, non ?

Oui, ca met le CI en erreur et les test jenkins en erreur.

Le problème vient du fait que si cet état dure plusieurs semaines ca devient embêtant car on risque de ne plus regarder ces erreurs et de passer à côté de vrais erreurs sur les sites en prod (ex, le générateur de Rennes qui ne marchait plus suite à la migration de la gw).

Ce que je veux faire, c'est pouvoir mettre Strasbourg dans la branche master du reference-repository. Vu qu'on a commencé à installer le site, on a généré plusieurs configurations du site: celle du DHCP et du DNS. Le problème, c'est que si on laisse Strasbourg seul dans sa branche, à chaque fois que quelqu'un regénèrera une configuration DNS ou DHCP pour Grid'5000/Moyen de Calcul, il faudra faire attention à ne pas commiter de changements qui effacent la config' faite pour Strasbourg.

Là, j'ai mergé la branche Strasbourg dans la branche master parce qu'on a atteint une milestone dans ce qu'on s'était fixé comme objectif ce matin. Le soucis, c'est que les jobs de la CI liés à la génération du wiki déclenchent des erreurs parce qu'ils s'attendent à trouver Strasbourg dans le wiki. Comme j'ai trouvé ce champs 'production' dans les .yaml de site, je me suis dit que je pouvais m'en servir pour faire une distinction entre les sites déjà installés, et ceux qui sont en travaux.

Effectivement, je pense que ça serait dommage de garder des erreur dans le wikigen de la CI, parce qu'on pourrait rester quelques semaines sans pouvoir gérer correctement nos pages wiki.

Du coup l'idée, c'est de revert le commit quand Strasbourg sera dans un état plus avancé ? Vu que les "next if" sur certains générateurs ne correspondent qu'un hack vu l'état de l'installation actuelle de strasbourg (hack qui ne marcherait pas si on installe 2 sites simultanément et donc 2 sites dans 2 états plus ou moins avancés d'installation)

le site existe, pourquoi ne pas générer des pages wiki le concernant, même si elles ne listent pas de matériel pour l'instant ?

@alpetit Non je ne pense pas qu'on ait besoin de reverter le commit par la suite.

L'idée c'est que lorsqu'on commence l'installation d'un site, on le déclare dans le ref-repo, mais avec le paramètre 'production' à 'false', et on passe ce dernier à 'true' une fois que l'installation est terminée.

Pourquoi est-ce que tu dis que c'est un hack, et que ça ne fonctionnerait pas si on installait deux site en même temps ? Ce champs 'production' n'a même pas l'air d'être utilisé pour faire quoi que ce soit. (J'ai fait quelques grep dans le ref-repo pour voir où il pouvait être utilisé)

@lnussbau Je crois qu'on avait choisit de ne pas mettre Toulouse dans le wiki tout de suite pour éviter de laisser traîner des références à un site qui n'est pas encore utilisable par des utilisateurs lambdas.

La seule raison que je vois actuellement d'utiliser ce champs 'production', c'est pour la page environments qui n'arrive pas à builder. (Puisqu'elle cherche à accéder à l'API de Strasbourg, qui n'existe pas encore) Sinon,je pense que c'est une solution tout à fait acceptable oui.

à mon avis, soit on est OK avec l'idée que le site soit affiché partout, et on le met dans la branche master. soit on est pas OK avec ça, et on ne le met pas dans la branche master.

Par exemple, là, il est dans le motd, puisqu'il est dans la ref-api. Vas-tu corriger mkmotd pour utiliser ce booléen production ? Est-ce vraiment la peine de partir à la chasse à tous les endroits où on récupère la liste des sites, pour se limiter à ceux en production ? Ca ajoute un chemin de code à plein d'endroits, donc des bugs potentiels...

** Other sites: grenoble lille luxembourg lyon nantes rennes sophia strasbourg toulouse

Concrètement, pour strasbourg, pourquoi est-ce que tu as besoin qu'il soit dans la branche master de reference-repository si tôt dans le processus ?

autre exemple de problème posé par l'ajout dans la branche master:

$ clush -bw $(allsites frontend) true
frontend.strasbourg.g5k: channel 0: open failed: connect failed: No route to host
frontend.strasbourg.g5k: stdio forwarding failed
frontend.strasbourg.g5k: kex_exchange_identification: Connection closed by remote host
frontend.strasbourg.g5k: Connection closed by UNKNOWN port 65535
clush: frontend.strasbourg.g5k: exited with exit code 255

Je voulais mettre strasbourg dans le ref-repo pour que les fichiers de configuration qu'on génère pour puppet ne risquent pas d'être écrasés par des rake gen:puppet faits depuis le master.

C'était aussi pour tester ce qu'à fait Philippe en permettant de générer la ref-api sans qu'il n'y ait de cluster de déclaré.

Bon, le fait d'avoir la branche de strasbourg dans le master pose plus de soucis que c'est censé en résoudre, donc je vais revert mon merge.

@alpetit Non je ne pense pas qu'on ait besoin de reverter le commit par la suite.

L'idée c'est que lorsqu'on commence l'installation d'un site, on le déclare dans le ref-repo, mais avec le paramètre 'production' à 'false', et on passe ce dernier à 'true' une fois que l'installation est terminée.

Pourquoi est-ce que tu dis que c'est un hack, et que ça ne fonctionnerait pas si on installait deux site en même temps ? Ce champs 'production' n'a même pas l'air d'être utilisé pour faire quoi que ce soit. (J'ai fait quelques grep dans le ref-repo pour voir où il pouvait être utilisé)

Je n'ai pas en tête l'installation d'un site donc peut-être que je me trompe. Quand un site est mergé dans master les différents générateurs sont exécutés donc suivant l'état d'avancement de ce que tu as mergé dans master, tu peux ne vouloir exécuter que certains générateurs ou certaines parties de générateur.

Ca me parait difficile de coder un seul état temporaire, non ? C'est plutot du cas par cas suivant où tu en es dans l'avancement de l'installation ? D'où le fait que j'ai parlé de 'hack' et de 'revert' en voulant dire que l'utilisation du 'production' comme tu le proposes ne couvre uniquement que le cas de Strasbourg à l'instant t. Ex, si tu avais mergé la branche la semaine dernière, ce n'aurait peut-être pas suffit pour avoir tous les générateurs fonctionnels ? Il aurait peut-être fallut exclure d'autres parties ?

Mais encore une fois je ne maitrise pas les étapes d'installation d'un site et quel générateur (ou bout de générateur) doit être utilisé quand. Peut-être que cet état temporaire suffit et qu'il est documenté dans le doc (pas regardé).

marked this merge request as draft