Bac à idée #29665
[HAPY] La préparation du serveur à l’Upgrade-Auto doit gérer les doublons de VMs a redémarrer
0%
Description
Problème¶
La préparation d’un Hâpy avant Upgrade-Auto
tente d’arrêter des machines virtuelles qui peuvent être déjà arrêtée par un Upgrade-Auto
précédent.
Le problème se produit dans la condition suivante :
- Exécution de la procédure
Upgrade-Auto
- Un problème survient durant la procédure, elle s’arrête
- Exécution une deuxième fois de la procédure
Upgrade-Auto
(après avoir corrigé ce qui n’allait pas)
Le script pre_download/01-hapy
tentera d’arrêter des VMs déjà arrêtées.
Critères d’acceptation¶
- Sur un Hâpy a migrer
- Démarrer des machines virtuelles
- Créer un script qui fait planter la migration
cat > /usr/share/eole/upgrade/pre_download/02-break-upgrade <<EOF #!/bin/sh exit 1 EOF
chmod +x /usr/share/eole/upgrade/pre_download/02-break-upgrade
- Exécuter la procédure
Upgrade-Auto
- Une fois la procédure plantée, supprimer le script
/usr/share/eole/upgrade/pre_download/02-break-upgrade
- Exécuter la procédure
Upgrade-Auto
- Lors de la seconde exécution, il ne doit y avoir aucun message d’erreur durant l’exécution du script
01-hapy
- Après la procédure
Upgrade-Auto
, les machines virtuelles qui étaient démarrées au tout début doivent être en fonctionnement
Demande original¶
Bonjour,
Après avoir rencontré un soucis lors d'un Upgrade-Auto (Hapy 2.4 → EoleBase 2.5), lors d'une seconde relance de ce script le fichier /var/backups/eole/hapy/one-running-vms.ids
n'est ni purgé ni supprimé.
Ce qui engendre des problèmes :
- la liste des IDs des VMs est concaténée à la liste déjà sauvegardée
- les éventuelles suppressions de VMs entre temps ne sont donc pas prises en compte
Il faudrait à mon avis simplement supprimer ce fichier à chaque lancement du script Upgrade-Auto
Bien cordialement,
Camille Jactard
Historique
#1 Mis à jour par Daniel Dehennin il y a environ 4 ans
- Projet changé de Distribution EOLE à creole
J’avoue que cela me pose un petit soucis conceptuel, par exemple :
- Démarrage de la procédure d’Upgrade
- Plantage pour raison
X
ouY
mais après que les VM aient bien été arrêtées - Reprise de la procédure d’Upgrade après correction éventuelle de truc qui n’allaient pas
Dans ce cas, à la fin de la procédure, nous n’avons plus aucune trace de la liste des VMs qui sont a démarrer après l’Upgrade puisque la reprice de la procédure ne verra aucune VM devant être arrêtées.
Un autre cas,
- Démarrage de la procédure d’Upgrade
- Une des VMs ne s’arrête pas parcequ’elle ne supporte pas l’ACPI mais certaines VMs sont bien arrêtées
- Reprise de la procédure d’Upgrade après avoir géré manuellement la VM problématique
Dans ce cas, nous avons la même chose que le cas précédent, les VMs étant arrêtées en parallèle les VMs non problématiques ont eu le temps de s’arrêter pendant que l’on gère la VM problématique.
Nous pouvons, en revanche tenir 2 listes :
- la liste des VMs a arrêter durant l’exécution de la procédure, cette liste est écrasée à chaque fois
- la liste des VMs à qui nous avons demandé se s’arrêter et qui devront être démarrées à la fin de l’Upgrade
La première étant fusionnée à la seconde en supprimant les doublons.
#2 Mis à jour par Daniel Dehennin il y a environ 4 ans
- Tracker changé de Demande à Scénario
- Sujet changé de [HAPY] Erreur lors du Upgrade-Auto : Some VM could not be poweroff à [HAPY] La préparation du serveur à l’Upgrade-Auto doit gérer les doublons de VMs a redémarrer
- Description mis à jour (diff)
- Début
28/02/2020supprimé - Release mis à EOLE 2.6.2.3
#3 Mis à jour par Gilles Grandgérard il y a presque 4 ans
- Tracker changé de Scénario à Bac à idée
- Statut changé de Nouveau à Classée sans suite
voir réponse Daniel