Projet

Général

Profil

Tâche #30484

Scénario #30411: Traitement express MEN (28-35)

En 2.7.2 (au moins) il manque une dépendance pour gluster

Ajouté par Philippe Caseiro il y a plus de 3 ans. Mis à jour il y a plus de 3 ans.

Statut:
Fermé
Priorité:
Haut
Assigné à:
Début:
31/07/2020
Echéance:
% réalisé:

100%

Restant à faire (heures):
0.0

Description

Le démon Glusterfs n'est pas lancé après l'installation du paquet car il manque un paquet "rpcbind"

Une fois installé ce paquet le démon est fonctionnel.

Sans cette correction eole-glusterfs ne fonctionne pas.

Révisions associées

Révision 1777c6b0 (diff)
Ajouté par Joël Cuissinat il y a plus de 3 ans

  • 80_gluster.xml : cosmetik dico

Ref: #30484

Révision bd4038c7 (diff)
Ajouté par Joël Cuissinat il y a plus de 3 ans

Add rpcbind dependency for eole-glusterfs

Ref: #30484

Historique

#1 Mis à jour par Joël Cuissinat il y a plus de 3 ans

  • Assigné à mis à Joël Cuissinat
  • Tâche parente mis à #30411

#2 Mis à jour par Joël Cuissinat il y a plus de 3 ans

J'imagine que cela concerne la fonctionnalité décrite ici : http://eole.ac-dijon.fr/documentations/2.7/completes/HTML/ModuleHapy/co/ConfigurationHA.html

Je propose de monter une maquette dans ONE en prenant des notes afin de pouvoir en faire un test squash :)

#3 Mis à jour par Joël Cuissinat il y a plus de 3 ans

  • déployer 3 "aca.hapy Daily" en pensant à leur attribuer des noms différents (VM name) pour les identifier facilement dans l'interface
  • aller sur le 1er serveur (hapy1) et récupérer la configuration par défaut
    /root/mount.eole-ci-tests
    /mnt/eole-ci-tests/scripts/configure-vm.sh -Mconfigeol
    
  • GenConfig (mode expert)
    • Général -> Nom de la machine : hapy1
    • Interface-0 -> Adresse IP de l'interface 0 : 192.168.0.116
    • Virtualisation -> Activer le support pour la haute disponibilité OpenNebula : oui
    • Virtualisation -> Nom du nœud de virtualisation : hapy1 hapy2 hapy3
    • Virtualisation -> Index du serveur dans la liste des nœuds de virtualisation : 0
    • Virtualisation -> Adresse IP de la VIP OpenNebula
  • Enregistrer
  • aller sur le 2ème serveur (hapy2) et récupérer la configuration créée pour hapy1
  • Remplacer
    • nom_machine : hapy2
    • adresse_ip_eth0 : 192.168.0.117
    • one_ha_server_index : 1
  • instancier le module en répondant *non" à la question concernant l'inscription d'un noeud dans une grappe Hâpy
  • aller sur le 3ème serveur (hapy3) et récupérer la configuration créée pour hapy1
  • Remplacer
    • nom_machine : hapy3
    • adresse_ip_eth0 : 192.168.0.118
    • one_ha_server_index : 2
  • instancier le module en répondant *non" à la question concernant l'inscription d'un noeud dans une grappe Hâpy
  • instancier le module hapy1
  • répondre "oui" à la question suivante :
    Vous allez inscrire un noeud dans une grappe Hâpy
    Pour ce faire vous devez vous munir du mot de passe de l'utilisateur 'root' de chacun des noeuds
    Voulez-vous commencer ?
    

#4 Mis à jour par Joël Cuissinat il y a plus de 3 ans

  • Projet changé de eole-glusterfs à Distribution EOLE
  • Statut changé de Nouveau à En cours

#5 Mis à jour par Joël Cuissinat il y a plus de 3 ans

En 2.7.2, il y a une nouvelle variable non documentée : Nom de domaine (FQDN) associé à la VIP
eole-one-frontend:08e1df61be7cf

Je suppose quand dans le cadre des tests, nous pouvons l'initialiser à one.ac-test.fr => #30525

#6 Mis à jour par Joël Cuissinat il y a plus de 3 ans

J'ai ajouté deux tests squash pour valider la haute disponibilité OpenNebula mais cela ne règle pas la demande initiale...
  • HP-003-01 - Préparer les configurations Hâpy
  • HP-003-02 - Finaliser la mise en place du cluster

#7 Mis à jour par Joël Cuissinat il y a plus de 3 ans

En installant eole-glusterfs sur un Eolebase et en le configurant au feeling, on obtient assez vite une réponse claire :

root@eolebase:~# service glusterd start
Failed to start glusterd.service: Unit rpcbind.service not found.

Actuellement c'est le paquet 2.7.1-3 qui est distribué pour toutes les versions >= 2.7.1, on dirait que master est la seule branche de développement :

~/git/eole-glusterfs$ git branch -r
  origin/HEAD -> origin/master
  origin/develop
  origin/dist/eole/2.7.0/develop
  origin/dist/eole/2.7.1/master
  origin/master

Sauf que les derniers commits de la branche master n'ont jamais été empaquetés et ne le seront potentiellement jamais...

~/git/eole-glusterfs$ git cherry -v dist/eole/2.7.1/master master
- f1ec376b9f06c946096419fb3f97b679a29e434a Fix typo
+ a5195f85b03d0f3e6d0ed8cdfcd914ef5959e133 fix des droits sur le datastore
+ cdc0468977010f5a148d1269f44957dfd888668e glusterfs_servername => glusterfs_servername_index
+ 77244e15916e04a6de18cd1d0378e7e8c6ac7d9d reprends les droits du répertoire pour les réappliquer sur le point de montage
+ fe79beab8bf1c80faffb76f866d9713d0b7b909e better leader tests
+ 1f4570460e7409ee7a7d5de85811f11bf1628647 copie one_nodes > glusterfs_remote_servername et one_ha_server_index > glusterfs_servername_index si variable présente
+ ecc19efcdd48b599876d97f93ffd73fe53c3fc07 check all node in gluster 0
+ 4eeeb920fe2ff711bd6b0d77da406f31942a4e3b glusterfs sur un multi noeud
+ 1bdf528795ea5502424447f4f6180ef38cd88f75 activation sur les noeuds si plus de 2 noeuds

D'après Emmanuel, c'était pour "utiliser glusterfs avec 3 noeuds au lieu de 2" mais il n'est pas favorable à ce qu'on package la branche master sans vérification supplémentaire (NB : des variables ont notamment été renommées).

#8 Mis à jour par Joël Cuissinat il y a plus de 3 ans

J'ai donc sorti une branche 2.7.1/master et refait un paquet "toutes versions" à partir de la branche dist/eole/2.7.1/master.

=> eole-glusterfs 2.7.1-4

#9 Mis à jour par Joël Cuissinat il y a plus de 3 ans

  • Statut changé de En cours à Résolu
  • % réalisé changé de 0 à 100

#10 Mis à jour par Fabrice Barconnière il y a plus de 3 ans

  • Description mis à jour (diff)

#11 Mis à jour par Joël Cuissinat il y a plus de 3 ans

  • Statut changé de Résolu à Fermé
  • Restant à faire (heures) mis à 0.0

Vu

Formats disponibles : Atom PDF