Projet

Général

Profil

Scénario #34577

Mis à jour par Gilles Grandgérard il y a plus d'un an

La modification du paquet de contextualisation OpenNebula en 6.4 dans les Apps du Market a bloqué le fonctionnement de l'automatisation.

Ce scénario englobe en globe les modifications nécessaires et améliorations du processus de déploiement.

modifications:
- Les variables d'environnement LANG doivent être imposées pour que pexpect puisse gérer les messages
- Le paquet de contextualisation gère correctement le réseau --> suppression des 'setup_network' qui génèrent des messages "RTNETLINK answers: File exists" dans les logs...
- Le redimensionnement des Disques de la VM doit se faire AVANT 'instance' --> refactoring du code pour démarrer la VM sans provissioning, attente fin boot, arrêt, redimensionnement, puis re-démarrage avec provisionning
- En mode reconfigure, si la VM existe -> ne rien faire
- Le template est géré complètement par le script (plus de mode 'append')
- Le template final de la VM ne contient plus de CONTEXT. Normal, une fois la VM démarrée et rattaché à Zéphir, la contextualisation ne doit plus intervenir.

améliorations:
- le script d'ajout d'un market redémarre toujours OpenNebula --> uniquement si on ajout un market.
- le script de déploiement fonctionne avec 'instance' seul. L'obligation d'aller faire un 'instance' sur le module Hapy à chaque déploiement est contraignant. La gestion du reconfigure est ajoutée.
- les mises à jour de script ou credential supprime et recrée les FILE OpenNebula. Il existe un BUG dans OpenNebula (depuis longtemps...) qui bloque le re démarrage d'une VM. --> Utilisation de l'approche de l'automate de test : re-nomage des FILE (ave l'ID) et création d'un nouveau FILE. Idem pour zcreds.sc (avec SHA)
- L'ensemble des messages du déploiement d'une VM sont regroupés ensemble

mise en forme du code :
- Une fonction pour chaque commande OpenNebula (le nom des fonction = la commande OpenNebula)
- séparation des Opérations d'attente / commande
- Une seule fonction de mise à jour du template

L’algorithme est :

<pre><code class="python">
for vm in vms:
if isVmExiste(vmName):
Existe dèjà. pas de modification.
check power on
else:
import_apps from markets
onetemplate clone
check vm disk is persitante

if isVMDiskNeedResize
# phase 1 : boot sans provisionning, attente, puis poweroof, resize disk, terminate
onetemplate update BOOT1_SANS_PROVISIONING
onetemplate instantiate pour dimensionnement
wait vm status running démarrage pour dimensionnement
wait bootok_file_created
onevm poweroff
wait vm status poweroff "arrêt"
onevm disk_resize
# Wait for state DISK_RESIZE_POWEROFF to go off
wait vm status poweroff "arrêt pour redimensionnement"
onevm terminate
wait vm vanished

# phase 2 : boot avec provisionning,
onetemplate update BOOT2_AVEC_PROVISIONING
onetemplate instantiate "pour provisionning EOLE"
wait vm status running "démarrage provisionning"
monitor provisioning vm
# la fin de provisionning fait un 'halt' -> donc la vm est en poweroff
onevm terminate
wait vm vanished

# phase 3 : boot sans context
onetemplate update 'BOOT3_CONTEXT_FINAL'
onetemplate instantiate "pour usage final"
wait vm status "running", "démarrage final"

except:
...

</code></pre>

Retour