Scénario #20771
Hâpy doit permettre de définir le nom du cluster
100%
Description
Problème¶
Entre la version 2.4 et la version 2.6 la variable eole.creole.virtualisation.one_cluster_name n’existe plus ce qui rend l’identification de l’établissement depuis l’interface Sunstone plus difficile.
Proposition¶
- Réintroduire la variable avec la valeur par défaut
default - Rendre les scripts pre/post compatibles
- On ne créé pas la grappe mais on doit changer son nom lors du reconfigure (si un admin change le nom de la grappe dans Sunstone, on écrase sa valeur lors du reconfigure)
- Il faut toujours utiliser la variable creole ou l’ID
0
Demande initiale¶
Bonjour,
sur la version Hapy 2.6.1, je ne trouve pas la variable eole.creole.virtualisation.one_cluster_name (accessible en python) alors qu'elle existe en 2.4.*
Je ne l'ai pas vu dans les dicos non plus.
Comment définir le nom du cluster?
Cordialement
Anthony RAULT
Sous-tâches
Historique
#1 Mis à jour par Daniel Dehennin il y a presque 7 ans
- Assigné à mis à Daniel Dehennin
#2 Mis à jour par Daniel Dehennin il y a presque 7 ans
- Statut changé de Nouveau à Pas un bug
Bonjour,
Normalement, notre base de signalement est à réserver pour :- les bugs avérés (avec si possible la façon de les reproduire et/ou des fichiers de logs)
- les demandes d'amélioration / de nouvelles fonctionnalités
Pour les autres problèmes, il vaut mieux utiliser en priorité les listes de diffusion (ou si nécessaire un mail à eole@ac-dijon.fr).
Pour votre demande, il s’avère que depuis la version 5.0, OpenNebula créé une grappe par défaut nommée default avec l’ID 0, nous n’avons donc plus besoin de gérer cette information (#16797).
La variable one_cluster_name n’existe plus depuis la 2.6.0 :
root@hapy:~# CreoleGet one_cluster_name root - Variable inconnue one_cluster_name
Merci.
#3 Mis à jour par Anthony RAULT il y a presque 7 ans
Bonjour,
Je continue ici car je ne pas vu de liste de diffusion pour Hapy :-(
Si ce n'est un bug, c'est donc une régression:
Cette variable est intéressante pour nous (Académie de La Réunion) pour plusieurs raisons:
- Elle permet visuellement (Sunstone) de connaître l’établissement auquel appartient le ONE tant pour le personnel DSI que les informaticiens en établissement
- Plusieurs de nos scripts sont basés sur cette variable.
- Si nous centralisons la gestion des ONE en un seul master, comment connaître sur quel cluster je peux pousser un disque/template/VM?
- Nous recherchons de la stabilité et non de l’éclectisme dans la gestion des ONE.
Enfin, entre la 2.4.0 et 2.4.2, il y a eu des modifications sur les dicos; entre la 2.4.2 et la 2.6.1, il existe encore plus des changements sur ceux-ci. Je ne doute pas que vos choix soient motivés mais pourquoi il n'existe pas de rétrocompatibilité.
Il me semble qu'EOLE doit être un facilitateur...
Cordialement
#4 Mis à jour par Daniel Dehennin il y a presque 7 ans
- Tracker changé de Demande à Proposition Scénario
- Sujet changé de definir le nom du Cluster à Hâpy doit permettre de définir le nom du cluster
- Description mis à jour (diff)
- Statut changé de Pas un bug à Nouveau
- Assigné à
Daniel Dehenninsupprimé
Anthony RAULT a écrit :
Bonjour,
Je continue ici car je ne pas vu de liste de diffusion pour Hapy :-(
Effectivement.
Si ce n'est un bug, c'est donc une régression:
Cette variable est intéressante pour nous (Académie de La Réunion) pour plusieurs raisons:
- Elle permet visuellement (Sunstone) de connaître l’établissement auquel appartient le ONE tant pour le personnel DSI que les informaticiens en établissement
- Plusieurs de nos scripts sont basés sur cette variable.
Je passe la demande en proposition de scénario pour répondre à ces deux points.
Notez qu’il est possible de modifier le nom de la grappe dans l’interface Sunstone mais il semble que nos scripts n’utilisent pas l’identifiant de la grappe mais son nom :-/
- Si nous centralisons la gestion des ONE en un seul master, comment connaître sur quel cluster je peux pousser un disque/template/VM?
Cela sera assez difficile si vous avez un grand nombre d’OpenNebula.
Nous avons ouvert la demande OpenNebula#3872 afin de permettre ce type de fonctionnement mais ce n’est pas encore réalisé.
- Nous recherchons de la stabilité et non de l’éclectisme dans la gestion des ONE.
J’avoue ne pas bien comprendre ce point, avant la version 5.0 il fallait créer la grappe dans la base OpenNebula ce qu’il ne faut plus faire depuis la 5.0 (#16797).
Le but n’est pas de limiter le nombre d’utilisateurs de cette solution, bien au contraire, c’est d’ailleurs l’une des raisons pour laquelle nous avons écris un article de blog :
- Montrer un cas concret de mise en place des solutions EOLE sur Hâpy
- Identifier les points limitant son adoption et prévoir le résolution, je pense notamment à la possibilité de générer automatiquement des machines en se basant sur un Zéphir.
Enfin, entre la 2.4.0 et 2.4.2, il y a eu des modifications sur les dicos; entre la 2.4.2 et la 2.6.1, il existe encore plus des changements sur ceux-ci. Je ne doute pas que vos choix soient motivés mais pourquoi il n'existe pas de rétrocompatibilité.
Hormis le problème de cette variable, avez-vous identifié d’autres points bloquants sur la rétrocompatibilité ?
Il me semble qu'EOLE doit être un facilitateur...
Cela a bien toujours été notre but, il est par contre souvent difficile de savoir ce qui doit être maintenu et ce qui peut-être supprimé car nous n’avons que très peu de visibilité sur ce qui est utilisé par les académies.
Nous sommes désolés pour la gêne occasionnée.
#5 Mis à jour par Anthony RAULT il y a presque 7 ans
Bonjour,
Tout d'abord, je vous remercie de votre écoute bien vieilante.
Quelques éclaircissements en ce qui concerne l'éclectisme/stabilité:
Si nous ne pouvons pas modifier les même caractéristiques/paramètres d'un Hapy a travers différentes versions (2.4 -> 2.6 -> ..), nous nous trouvons avec des serveurs Hapy difficilement manageable car, par exemple, des noms de cluster identifiables et d'autres non.
En aparté a ce point, la modification des paramètres par défaut dans opennebula.conf ne sont pris en compte que pour les nouveaux objets (VM/template/image) car leurs paramètres des objets existants sont déjà enregistrés dans la base de données (ex.: modification du préfixe des disques sd->vd); en incombe a Opennebula.
Sur les différences entre les versions (non exhaustif):
2.4.0 <-> 2.4.2:
. eole.creole.virtualisation.vnets.vnet_range_end -> eole.creole.virtualisation.vnets.vnet_range_size
2.4 <-> 2.6:
. paramètres type texte sont obligatoirement unicode (ex: one_video_driver)
. la branche ovs_sw_zones n'est plus accessible via eole.creole.virtualisation mais via eole.creole.commutateur_virtuel
Je m'amuse beaucoup aussi avec les différences SysV -> systemd
Voila, j’espère avoir répondu a vos interrogations et si vous désirez d'autres éclaircissements, n’hésitez pas.
Cordialement
#6 Mis à jour par Gilles Grandgérard il y a plus de 6 ans
- Tracker changé de Proposition Scénario à Scénario
#7 Mis à jour par Anthony RAULT il y a environ 6 ans
Bonjour,
Pourrait-on avoir une date d’intégration de cette demande car bloquante pour nos déploiements hapy 2.6?
Cordialement
#8 Mis à jour par Luc Bourdot il y a environ 6 ans
- Echéance mis à 20/04/2018
- Version cible mis à sprint 2018 14-16 Equipe MENSR
- Début mis à 03/04/2018
#9 Mis à jour par Joël Cuissinat il y a environ 6 ans
- Release mis à EOLE 2.6.2.1
#10 Mis à jour par Scrum Master il y a environ 6 ans
- Points de scénarios mis à 4.0
#11 Mis à jour par Joël Cuissinat il y a environ 6 ans
- Assigné à mis à Daniel Dehennin
#12 Mis à jour par Joël Cuissinat il y a presque 6 ans
- Statut changé de Nouveau à Terminé (Sprint)