Project

General

Profile

Scénario #20771

Hâpy doit permettre de définir le nom du cluster

Added by Anthony RAULT almost 4 years ago. Updated almost 3 years ago.

Status:
Terminé (Sprint)
Priority:
Normal
Assigned To:
Category:
-
Start date:
04/04/2018
Due date:
04/20/2018
% Done:

100%

Estimated time:
(Total: 10.00 h)
Spent time:
0.50 h (Total: 13.55 h)
Story points:
4.0
Remaining (hours):
0.00 hour
Velocity based estimate:
Release:
Release relationship:
Auto

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


Subtasks

Tâche #23553: Permettre aux utilisateurs de définir le nom du cluster par défautFerméDaniel Dehennin

Tâche #23594: S’assurer que le service oned est fonctionnel avant d’exécuter le script postserviceFerméDaniel Dehennin

Tâche #23642: Documenter la "nouvelle" variableFerméJoël Cuissinat

Tâche #23653: Ajouter un test squashFerméJoël Cuissinat

History

#1 Updated by Daniel Dehennin almost 4 years ago

  • Assigned To set to Daniel Dehennin

#2 Updated by Daniel Dehennin almost 4 years ago

  • Status changed from Nouveau to 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 Updated by Anthony RAULT almost 4 years ago

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 Updated by Daniel Dehennin almost 4 years ago

  • Tracker changed from Demande to Proposition Scénario
  • Subject changed from definir le nom du Cluster to Hâpy doit permettre de définir le nom du cluster
  • Description updated (diff)
  • Status changed from Pas un bug to Nouveau
  • Assigned To deleted (Daniel Dehennin)

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 Updated by Anthony RAULT almost 4 years ago

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 Updated by Gilles Grandgérard about 3 years ago

  • Tracker changed from Proposition Scénario to Scénario

#7 Updated by Anthony RAULT about 3 years ago

Bonjour,

Pourrait-on avoir une date d’intégration de cette demande car bloquante pour nos déploiements hapy 2.6?

Cordialement

#8 Updated by Luc Bourdot about 3 years ago

  • Due date set to 04/20/2018
  • Target version set to sprint 2018 14-16 Equipe MENSR
  • Start date set to 04/03/2018

#9 Updated by Joël Cuissinat about 3 years ago

  • Release set to EOLE 2.6.2.1

#10 Updated by Scrum Master about 3 years ago

  • Story points set to 4.0

#11 Updated by Joël Cuissinat about 3 years ago

  • Assigned To set to Daniel Dehennin

#12 Updated by Joël Cuissinat almost 3 years ago

  • Status changed from Nouveau to Terminé (Sprint)

Also available in: Atom PDF