Distribution EOLE » Qualification, Test et Intégration continue » eole-ci-tests

h1. Avant Propos

todo

h2. Le modele de réseau

h3. Ajouter le partage 'eole-ci-tests' sur une VM

Si vous avez besoin de monter 'eole-ci-tests' sur une VM, il faut ajouter une ligne RAW dans la configuration du modèle :

<pre>

RAW=[TYPE="kvm",DATA="<devices><filesystem type='mount' accessmode='squash'><source dir='/var/lib/one/datastores/eole-ci'/><target dir='eole-ci'/></filesystem></devices>" ]

</pre>

Une fois la machine instanciée, pour monter le partage il faut executer :

<pre>

mkdir /mnt/eole-ci-tests

mount -t 9p -o trans=virtio eole-ci /mnt/eole-ci-tests -oversion=9p2000.L

</pre>

La mise à jour du git 'eole-ci-tests' est faite toutes les 15 minutes par Jenkins.

h3. Modèle de réseau de test pour les VM Nebula

!reseaux_type.png!

h2. Les fichiers de configuration

* ModulesConf.yaml

Ce fichier décrit globalement les modules Eole.

Il est utilisé pour :

* générer les context de chaque modele de VM

* générer les fresh install eole ( <module>-<version>-<architecure>.fi dans nebula )

* générer les daily ( <module>-<versionMajer>-daily-<architecure>.fi dans nebula )

<pre>

eoleVersions:                           # liste des numéros de version géré dans l'env de test

- 2.3.13-rc1

- 2.4.0

gateways:                               # liste des gateways par utilisateur Nebula

  - user: gilles                        # le nom de l'utilisateur Nebula 

    prefixe: ggg                        # le prefixe a utilisé pour les templates, switchs, et vm

    ipsweole: 82                        # l'adresse ip sur le réseau sw-eole

modules:                                # La liste des modules connus

  - module: base                        # le nom du module dans les modeles

    memoire: 1024                       # permet de définir la mémoire requise pour ce module

    versions:                           # la liste des versions de ce module

    - versionMajeur: 2.3                # dans la version 2.3..

      menu: 1                           # ... le module est en position 1 sur le menu d'installation 

      actif: oui                        # indique que le module est déactivé dans les tests

      container: non                    # permet d'indiquer aux tests qu'il faut faire l'installation des conteneurs ou non

    - versionMajeur: 2.4    ...

      menu: 1

...

</pre>

* ModeleReseautestEole.yaml

Attention: Les gateway de chaque réseau est toujours l'ip .1 de chaque réseau

Il est utilisé pour :

* générer les context de chaque modele de VM

* générer les templates de chaque machine

* démarrer les VM lors des tests en Itégration Continue

<pre>

bases:                                  

  - base: eole23                        # nom de la base utiliser dans la description d'une machine (cf ci dessous )

    versionMajeur: 2.3                  # quel est la version majeur a utiliser. La version mineur sera déduite du fichier ModulesConf.yaml

  - base: winpcadmin

    imageNebula: windows-xp-sp3.vm      # si imageNebula est presente, alors la base n'est pas EOLE ==> windows ou autre

    architecture: amd64                 # dans ce cas, l'architecture doit être définie 

....

switchs:                                # c'est la liste des switchs nécessaire à ce modele

  - sw: academie                        # c'est l'id du switch . dans Nebula, il correspond à "SW-<pefixe>-academie"

    network: 192.168.0                  # c'est le réseau associé à ce switch

   ...

networks:                               # ce tag est la racine de description de tous les établissements 

  - etablissement: aca                  # ce tag correspond à un etablissement dont le nom est 'aca'. Toutes les machines définies sous l'établissement seront 

                                        # préfixées par <prefixe_user>.<etablissement>

    machines:                           # c'est la liste des machines

    - machine: eolebase                 # chaque machine a : un nom (eolebase). 

                                        # le template de cette machine sera <prefixe_user>.<etablissement>.<machine> (ggg.aca.eolebase) 

                                        # le nom dns sera : <machine>.<etablissement>@ac-test.fr pour les etablissement et

                                        #                   <machine>@ac-test.fr pour les machines en académie

                                        # Ce nom est important car il va définir un template dans les configurations enregistrées dans eole-ci-test

      module: base                      # c'est le nom du module (cf ModulesConf.yaml). La valeur est obligatoire pour les modules Eole

      base: eole24                      # identifie l'image de base à utiliser eole23, eole24, win...

      switchs:                          # ce tag décris les liens de la machine

      - sw: academie                    # le nom du switch 

        host: 24                        # l'ip sur ce switch

...

    - machine: sphynx24a

      module: sphynx

      base: eole24

      switchs:                          # exemple avec plusieurs switchs

      - sw: academie

        host: 11

      - sw: agriates

        host: 11

      - sw: ha1

        host: 11

...

    - machine: pcadmin                  # exemple pour un poste client

      base: winpcadmin

      switchs:

      - sw: admin1

        host: 20

...

</pre>

* test.yaml

todo

h1. Installation

h2. Récupération du dépot eole-ci-test

Faire :

<pre>

ssh://git@dev-eole.ac-dijon.fr/eole-ci-tests.git

</pre>

h2. Ajout de la gateway dans le fichier ModulesConf.yaml 

il faut créer une entré dans "gateways" de la forme 

<pre>

  - user: gilles

    prefixe: ggg

    ipsweole: 82

</pre>

* Le prefixe sera ajouter à tous les templates, et à toutes les VM démarrées.

  Les switchs auront la forme SW-<prefixe>-<switch_dans_modele>

* ipsweole est l'ip a utilisr dans 192.168.230 comme gateway vers le réseau

h2. Ajout de la clef publique ssh dans eole-ci-tests/security/authorized_keys

Les clefs publiques SSH preentent dans eole-ci-tests/security/authorized_keys sont automatiquement concatenées dans /root/.ssh/authorized_keys au 1er démarrage de la VM.

L'acces a chaque VM peut se faire sans mot de passe.

Utiliser le nom 'user@hostname' pour votre fichier de cle.

h1. Creation d'un test

todo

h1. Lancement dans jenkins

h2. Mise à jour de "eole-ci-tests" sur toutes les VM

todo

h2.