Category: Solution logicielle

License

XtremWeb-HEP est sous license GPL V3.


This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see .

Téléchargements

Java 1.7 est nécessaire pour compiler et exécuter XWHEP 9.0.0 et suivant
Java 1.6 est nécessaire pour compiler et exécuter XWHEP 5.9.0 et suivant

• XtremWeb-HEP 9
• XtremWeb-HEP 8
• XtremWeb-HEP 7

SVN

Vous pouvez télécharger le projet depuis notre serveur SVN.

Pour télécharger une version spécifique (par exemple la 9.0.2) :

svn co https://svn.lal.in2p3.fr/projects/XWHEP/tags/9.0.2


XtremWeb-HEP 9 introduit le "offering and billing" pour permettre de créer un service "payant". D’autre part cette version permet de faire tourner des applications "Hadoop".

A la une

La version 9.0.0 de XtremWeb-HEP est un tournant majeur pour le monde des grilles de PC.

Pour la première fois, des applications "Big Data" peuvent être exécutées sur une plate forme hybride volontaire.

Documentation

La documentation est disponible ici.

Suivi de bugs

Vous pouvez accéder à notre serveur trac.

Versions

– 9 octobre 2014 : XWHEP 9.0.6

• Corrections (Cf Trac)
  1. la gestion des volumes dans les machines virtuelles
• Nouvelles fonctionnalités
  • aucune

– 8 septembre 2014 : XWHEP 9.0.3

• Corrections (Cf Trac)
  1. un bug a été corrigé dans le paquet RPM du worker
• Nouvelles fonctionnalités
  • aucune

– 5 septembre 2014 : XWHEP 9.0.2

• Corrections (Cf Trac)
  1. la gestion des machines virtuelles
  2. la gestion des distributions
• Nouvelles fonctionnalités
  • aucune

– 25 août 2014 : XWHEP 9.0.1

• Corrections (Cf Trac)
  1. la version 9.0.0 a introduit un bug dans la gestion du heartbeat signal; ceci est corrigé
  2. la version 9.0.0 a introduit un bug dans la gestion des applications VirtualBox; ceci est corrigé
• Nouvelles fonctionnalités
  • aucune

– 20 juin 2014 : XWHEP 9.0.0

• Corrections (Cf Trac)
  1. la database a été réarchitecturée
  2. la serializatiion XML a été améliorée
• Nouvelles fonctionnalités
  • Mécanismes de "Offering and Billing"

XtremWeb-HEP 8 introduit la virtualisation en permettant aux utilisateurs de soumettre leurs propres machines virtuelles. XtremWeb-HEP 8 implémente un niveau de sécurité au niveau des standards de la grille.

A la une

XtremWeb-HEP 8.3.0 prend en charge les certificats certifiés par une Autorité de Certification

La version 8.3.0 de XtremWeb-HEP est un tournant majeur pour le monde des grilles de PC.

Pour la première fois, la sécurité d’une plate forme de calcul global atteind le niveau des standards de la grille de calcul.

XtremWeb-HEP 8.0.0 prend en charge les applications virtuelles

Avec XtremWeb-HEP 8, pour la première fois, les utilisateurs peuvent soumettre leurs propres machines virtuelles sur des PC volontaires.

Grâce à la technologie IBIS SmartSockets, les utilisateurs peuvent se connecter en toute sécurité (à travers un tunnel ssh) à leur VM, même si elle tourne sur un PC volontaire derrière un pare-feu.

La convergence entre les grilles de PC et le Cloud est là.

En date du 20 janvier 2012, cette version est installée au LAL pour les tests finaux. Le middleware sera mis en ligne à la fin de ces tests.

Un nouveau site web est disponible: Flying-Grid.org.

Documentation

La documentation est disponible ici.

Suivi de bugs

Vous pouvez accéder à notre serveur trac.

Versions

– 7 mai 2014 : XWHEP 8.3.3

• Corrections
  1. SQL statements must always comply with referential integrity
  2. LiveCD Ubuntu security hole
  3. Live CD kernel console
  4. On insertion of a new Work inside the XtremWeb-HEP database, ownerUID must NOT be null
  5. The ‘xwconfigure’ script must generate all UIDs in lowercase
  6. On insertion of a new Work inside the XtremWeb-HEP database, status must NOT be null
  7. On insertion of a new Data as work result inside the XtremWeb-HEP database, status must NOT be null
  8. Linux Live CDs for submission to XtremWeb-HEP must provision separate disks for application, input data and output data
  9. Removing a work does not delete all associated tasks
  10. update db does not work
• Nouvelles fonctionnalités
  • n/a

– 12 novembre 2013 : XWHEP 8.3.2

• Corrections
  1. Ibis Smartsocket Hub network
  2. sonar versionning error
  3. server generated tasks with bad ‘workUID’ in the database
  4. goups without session should be created with ‘sessionUID’ = NULL
  5. smartsocket proxy usage
  6. proxy should close streams
  7. worker debian package error
  8. Ibis Smartsockets Hub configuration
• Nouvelles fonctionnalités
  • n/a

– 7 octobre 2013 : XWHEP 8.3.1

• Corrections
  1. https://trac.lal.in2p3.fr/DGHEP/ticket/134 et https://trac.lal.in2p3.fr/DGHEP/ticket/135: il y a désormais un paquet d’installation spécifique pour la configuration du serveur.
• Nouvelles fonctionnalités
  • n/a

– 18 septembre 2013 : XWHEP 8.3.0

• Corrections
  1. https://trac.lal.in2p3.fr/DGHEP/ticket/120 : le serveur peut maintenant être certifié par une Authorité de Certification
  2. https://trac.lal.in2p3.fr/DGHEP/ticket/123 : le dashboard affiche maintenant l’adresse mail comme login
  3. https://trac.lal.in2p3.fr/DGHEP/ticket/126 : pour soumettre un job depuis le dashboard on doit selectionner une et une seule application
  4. https://trac.lal.in2p3.fr/DGHEP/ticket/122 : le dashboard est désormais entièrement transféré avec le protocole https
  5. https://trac.lal.in2p3.fr/DGHEP/ticket/128 : une page d’erreur s’affiche dans le browser du client, en cas de problème, quel qu’il soit
• Nouvelles fonctionnalités
  • n/a

– 24 juin 2013 : XWHEP 8.2.3

• Corrections
  1. amélioration de l’aide en ligne du client (CLI et REST API)
  2. un bug corrigé dans la suppression des sessions (https://trac.lal.in2p3.fr/DGHEP/ticket/114)
  3. un trou de sécurité corrigé: les certificats et mot de passe ne doivent pas circuler sur le réseau(https://trac.lal.in2p3.fr/DGHEP/ticket/109)
  4. amélioration de OpenID: le serveur retourne le status HTML 401 en cas d’erreur d’authetification (https://trac.lal.in2p3.fr/DGHEP/ticket/116)
  5. la soumission de job par l’interface Web a été corrigée; l’utilisateur peut maintenant sélectionner des données en entrée (https://trac.lal.in2p3.fr/DGHEP/ticket/117)
• Nouvelles fonctionnalités
  • n/a

– 7 juin 2013 : XWHEP 8.2.2
• Corrections
  1. un bug corrigé dans l’insertion de session; le server doit positionner le champ owneruid si le client ne l’a pas fait
  2. une exception et un code d’erreur sont désormais levés si le client tente d’insérer un objet de type non insérable: host et task
  3. certaines parties de code ont été réécrite plus POO
  4. un bug corrigé dans le client, au niveau du parser de macro
• Nouvelles fonctionnalités
  1. n/a

– 16 avril 2013 : XWHEP 8.2.1
• Corrections
  1. l’encodage est forcé à UTF-8
  2. un bug de synchronisation inter-thread a été corrigé au niveau du serveur
• Nouvelles fonctionnalités
  1. n/a

– 26 février 2013 : XWHEP 8.2.0

• Corrections
  1. les LiveCD sont désormais configurés comme suit
     – le login est maintenant “vmuser” et non plus “xwuser”
     – le script pour créer un nouveau LiveCD est maintenant dans /usr/local/sbin/ (ubuntu_crealtelivecd.sh ou sl5_createlivecd.sh)
     – l’utilisateur “vmuser” et dans /etc/sudoers afin de lui permettre d’exécuter /sbin/poweroff et /usr/local/sbin/ (ubuntu_crealtelivecd.sh ou sl5_createlivecd.sh)
     – dirsetup n’est plus autorisé: c’était un trou de sécurité
     – context.sh est exécuté à la fin du process de boot

  2. Executor : un bug corrigé dans le process de nettoyage de fin d’exécution
  3. Web Interface v0.2 :
     – l’aide a été mise dans le “XtremWeb-HEP User Guide”
     – introduction des Web Workers

  4. la contextualisation de la Virtualization suit désormais les recommandations de "HEPiX Virtualization Working Group" (http://grid.desy.de/vm/hepix/vwg/doc/html/index.shtml)
  5. des bugs corrigés dans les scripts shell
  6. le code a été nettoyé pour une meilleur utilisation de la librarie "Jetty"
  7. les librairies suivantes ont du être mises à jour pour intégrer OpenId
     – jetty from 6.1.7 to 8.1.8
     – log4j from 1.2.9 to 1.2.17
     – slf4j from 1.5.3 to 1.7.2
     – servlet api from 2.5 to 3.0
• Nouvelles fonctionnalités
  1. introduction du mécanisme de WALLCLOCKTIME
  2. introduction du status RESULTREQUEST
  3. introduction de la variable FORCENEWUID dans la configuration des workers, afin de faciliter le déploiement des workers sur un cloud
  4. les jobs peuvent maintenant être retrouvés par status
  5. introduction de OpenId pour faciliter l’utilisation de la platform

– 25 juin 2012 : XWHEP 8.1.2

– Corrections
1. l’ordonnauceur a été amélioré : il prend maintenant correctement en compte "hosts.incomingconnection" ainsi que quot;exptedhost"
2. le bridgee DG – SG est compatible avec l’application partagée "VirtualBox"
3. des corrections ont été apportées concernant la registration d’application et la gestion de tâches
4. les fichiers temporaires sont maintenant correctement effacés
5. l’interface REST a été entièrement r éécrite. L’élément racine <xwhep></xwhep> doit être présenté. Exemples:
   – pour envoyer une application:
   https://server/sendapp/?XWPARAM=
   – pour retrouver les applications
   https://server/getapps
6. un bug corrigé dans le download des données par HTTP
7. SmartSocket fonctionne correctement; les communications inter noeuds sont implémentées; merci à Jason Maassen de Netherlands eScience Center à Amsterdam, pour son aide

– Nouvelles fonctionnalités

1. la création des live CD peut être customisée
2. le client peut être utilisé pour créer un SmartSockets end point, indépendemment de toute tâche (e.g. monter le file système du client dans une VM)
3. un nouveau package Mac OS X : "xwhep.vworker" pour déployer le middleware dans une VM
4. le server a une interface Web disponible par HTTPS

– May 3rd, 2012 : XWHEP 8.0.2

– Corrections
1. l’ordonnanceur a été amélioré : il tien désormais compte de hosts.incomingconnection
2. l’ordonnanceur utilise le champ “expectedhost” qui permet à un utilisateur de spécifier la ressource volontaire qui doit exéctuer le job.
   Notons que si cette machine ne vient pas prendre de job ou si cette machine ne répond pas aux exigences (OS, CPU…), le job ne sera jamais exécuté

3. le bridge DG vers SG est compatible avec les applications partagées. L’application VirtualBox peut donc être utilisée sur les ressource EGI
4. la gestion des applications et des tâches ont été améliorées
5. le client nettoie correctement ses fichiers temporaires
6. l’interface REST a été entièrement réécrite. L’utilisateur doit avoir un ertificat X509 valide.
   L’élément racine doit être utilisé
   Exemple:
   • https://server/sendapp/?XWPARAM=: pour soumettre une application
   • https://server/getapps : pour retrouver la liste des applications enregistrées
   • https://server/getusers: pour retrouver la liste des utilisateurs enregistrés
   • etc.
   • https://server/get/objectUID : pour retrouver un object spécifique

– Nouvelles fonctionnalités

1. la création des LiveCD peut être customisée en fournissant des fichiers optionnels:
   • un fichier texte ‘user.packages’ pour spécifier des packages optionnels; ce fichier doit contenir une liste de packages séparés par des espaces
   • un fichier texte ‘user.hostname’ pour spécifier un host name. Ce fichier doit contenir le host name et lui seul.
   • tout fichier de package et installé au vol (*.rpm or *.deb, en fonction de l’OS)
2. le client peut créer des SmartSockets end point, indépendemment de tout job.
   Cela peut être utile pour creer des tunnels SmartSockets de la VM au client (ex. monter le client FS dans la VM)

3. un nouveau package OS X “xwhep.vworker” pour deployer le middleware dans une VM (typiquement pour tourner un worker dans une VM)

-20 février 2012 : XWHEP 8.0.1

– Corrections
1. un bug corrigé dans la gestion des dépassements de délai au niveau des communications: la reconnection est maintenant automatique
2. le client compresse désormais les données automatiquement, si nécessaire
3. les workers ne doivent pas utiliser le mode connecté introduit dans la version 7.4.0
4. les workers et le server ne doivent pas utiliser de terminal (setProperty(“java.awt.headless”, “true”))
   (Cf http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/)

5. un bug corrigé dans l’utilisation des URI : les ampersand sont maintenant acceptés s’ils sont écrits sous la forme “&amps;”
6. un bug corrigé au niveau du client dans l’utilisation des fichiers XML (avec “–xwxml”)
7. dans le client, la gestion des groupes d’utilisateurs a été corrigée

– Nouvelles fonctionnalités

1. les workers ont de nouveaux attributs:
   • shared applications : la liste des applications partagées par la ressource
   • shared library : la liste des librairies partagées par la ressource
   • shared data : la liste des données partagées par la ressource
   • incomingconnections : un booléen indiquant si la ressource accepte la gestion des tunnels SmartSocket l’intergiciel ne modifie en aucune manièere le pare-feu de la ressource
2. utiliation de IBIS SmartSockets pour la gestion des tunnels de communication
3. une nouvelle option pour le client KEEPZIP (pour le debugging)
4. les works ont de nouveaux attributs:
   • readydate : date à laquelle la ressource a reçu le work
   • datareadydate : date à laquelle la ressource a reçu toutes les données du work
   • compstartdate : date à laquelle le work a été lancé par le worker
   • compenddate : date à laquelle le work a été terminé par le worker
5. les tasks ont désormais leur prorpre UID (elles avaient celui de leur work associé jusqu’à présent). Ceci permet de garder trace de toutes les tâches. On peut donc maintenant suivre toutes les tentatives de calcul pour un work donné.
6. un work peut être modifié par son propriétaire. Ceci est une demande de SpeQulOS (EDGI JRA2)
7. on peut maintenant indiquer le path de stockage pour chaque entrée du cache (sinon le path par défaut est utilisé). Ceci est nécessaire pour les interconnections XWHEP/Bitdew (en cours de dévéloppement)

Les développements logiciels sont suivi sur un serveur "trac"Le suivi de nos développements logiciel est disponible sur notre serveur "trac": https://trac.lal.in2p3.fr/DGHEP/report/9.

Nous avons démarré le processus de gestion de la qualité du code logiciel avec Sonar.

Vous êtes invités à suivre ce process de qualité logiciel pour XtremWeb-HEP 8+ ici.

Documentation

La documentation est disponible ici.

Suivi de bugs

Vous pouvez accéder à notre serveur trac.

Versions

Foire Aux Questions

• Comment savoir si la dernière version est stable?
  • Penser à vérifier si elle a été déployée au LAL
• Comment tester la plate-forme?
  • Nous vous proposons des paquets prêts à l’emploi
• Où trouver le LiveCD?
  • Vous pouvez télécharger le LiveCD

• 1er septembre 2010 : XWHEP 6.0.2
  • Corrections
    1. un bug corrigé dans le script xwtar.sh qui génère l’archive des fichiers sources (cette archive est maintenant correctement générée).

• 19 juillet 2010 : XWHEP 6.0.1
  • Corrections
    1. cette version insère les scripts de vérification et de configuration de la base de données qui étaient manquant dans la version 6.0.0

• 8 juillet 2010 : XWHEP 6.0.0
  • Corrections
    1. un bug corrigé au niveau du téléchargement des données : si un fichier n’est pas disponible au niveau du serveur, la partie distribuée (worker, client) en est correctement informée
    2. un bug corrigé dans la gestion du signal “alive” du côté du serveur
    3. un bug corrigé dans les paquets d’installation
    4. xwversion retourne 1 si le client devrait être mis à jour
    5. un bug corrigé dans la gestion des données (WIN32 worker)
    6. xwconfigure introduit les paramètres –newkeystore et–newalias. Par
       défaut les keystores sont crées s’ils n’existe pas et restent inhangés sinon.
       • –newkeystore peeut être utilisé pour forcer la regénération du keystore. Ceci annule tout déploiement éventuel.
       • –newalias peut être utilisé pour créer un nouvel alias dans le keystore existant.
         Ceci permet d’utiliser un déploiement au delà de la date d’expiration du keystore en cours.
  • Nouvelles fonctionnalités
    1. paquets RPM et Debian pour le client
    2. nouvelles colonnes dans la table “Host”
       • -osversion
       • -javaversion
       • -javadatamodel
    3. la définition des applications permet désormais de gérer les binaires Windows X86_64
    4. Java 6 SystemTray

• 30 juin 2010 : XWHEP 5.9.1
  • Corrections
    1. un bog corrige dans les requêtes SQL

• 28 avril 2010 : XWHEP 5.9.0
  • Corrections
    1. mise à niveau des installeurs Mac OS X : ils sont maintenant compatible toutes versions (y compris 10.6)
    2. le (un)marshalling XML amélioré : gain des performances jusqu’à 20% (voir ci après)
    3. Les scripts xwhepgenserverkey, xwhepgenworkerkey, xwhepgenclientkey sont remplacés par le seul script xwhepgenkeys qui est automatiquement généré par xwconfigure
  • Nouvelles fonctionnalités

    la plate-forme est maintenant capable de mettre automatiquement à jour la clé publique du serveur. Cette fonctionnalité doit être mise en oeuvre avant que la clé actuelle n’expire.

    • Sujet : utiliser un déploiement au delà de la validité de la clé initiale du serveur.
    • Quoi: distribuer automatiquement la clé publique du serveur aux workers et (sur demande) aux clients.
    • Quand: avant que la clé actuelle du serveur n’expire
    • Comment :
      1. créer une nouvelle clé pour le serveur avec le script xwhepgenkeys
      2. insérer le keystore du worker ainsi mis à jour (containant donc les clés publiques du serveur actuelles et nouvelles) en tant que donnée publique
      3. arrêter le serveur
      4. positionner la variable keystore.uri dans le fichier xtremweb.server.conf
      5. redémarrer le serveur
    • Securité : La sécurité est toujours assurée :
      • les workers et les clients doivent posséder la clé actuelle du serveur pour pouvoir télécharger le nouveau keystore
      • le téléchargement est crypté
      • les workers et les clients doivent présenter une identité valide pour ce téléchargement
      • le keytore distribué ne contient que des clés publiques

  XML un/marshalling has been improved. This results to an 20% performances increase as shown in the two next figures which represent the client execution time to retreive 1000 jobs from server of our XWHEP deployment at LAL. In the first figure we can see that the client needed more than 100 seconds using XWHEP 5.8.0; in the second figures less than 80 seconds is now needed using XWHEP 5.9.0.

  
  
  

• 5 mars 2010 : XWHEP 5.8.2
  • Corrections
    1. un bug corrigé les scripts d’initialisation

• 26 février 2010 : XWHEP 5.8.1
  • Corrections
    1. le script xwhep.bridge.pl a été corrigé pour être compatible avec les versions 5.8.x

• 24 février 2010 : XWHEP 5.8.0
  • Corrections
    1. le script xtremweb.tests.pl a été corrigé
    2. worker : un bug corrige dans l’envoi des résultats
    3. serveur : l’ordonnanceur peut être défini dans le fichier de config et chargé au lancement
    4. l’ordonnanceur a été totalement réécrit: il était buggé, conceptuellement erroné et ne gère pas les tâches équitablement entre les utilisateurs. Dans cette version, l’ordonnanceur :
       • n’utilise plus de cache DB pour éviter des fuites de mémoires
       • améliore l’utilisation des requêtes SQL
       • a l’entière responsabilité de la gesion des tâches:
         • retreive() passe les tâches de WAITING a PENDING
         • select() gère les tâches PENDING sur requête des workers
       • toutefois cette version ne gère toujours pas les tâches équitablement entre les utilisateurs (on est toujours en 1er arrivé 1er servi 🙁 )
    5. les logins des utilisateurs peuvent être réutiliser (le login d’un utilisateur effacé peut être réutilisé pour un nouvel utilisateur)
    6. les noms des groupes d’utilisateurs peuvent être réutiliser (le nom d’un groupe effacé peut être réutilisé pour un nouveau groupe)
    7. les mots de passe ne transitent plus
    8. les processeurs X86_64 sont correctement pris en charge pour les machines Apple
    9. des fuites de mémoires ont été corrigées au niveau du serveur. Les graphes ci dessous montrent l’utilisation de la mémoire par le serveur. Le 1er montre une utilisation trop importante avec la version 5.7.7 : il utilise jusqu’à 600Mb. Le 2nd montre une utilisation beaucoup plus raisonnable et surtout très stable avec la version 5.8.0 : le server se contente de 288Mb.

       
       

  • Nouvelles fonctionnalités.

    Certaines nouvelles fonctionnalités sont introduites afin d’améliorer le confinement et la sécurité.

    • les droits utilisateurs ont été légèrement modifiés: ADVANCED_USER permet de gérer des groupes utilisateurs. Conséquences : pour chaque groupe, il faut définir un administrateur pour gérer ce groupe (users, applications)
    • tout objet peut maintenant être confiné: ils ont tous les champs OWNERUID et ACCESSRIGHTS (AR).
    • xwchmod s’applique donc à tout objet

    Conséquences :

    • les identités administrator et worker sont privées (AR : 0x700) et n’apparaissent donc pas avec la commande xwusers
    • on peut confiner les groupes utilisateurs (AR: 0x750)
    • les utilisateurs d’un groupe hérite leurs AR de leur group
    • les utilisateurs doivent être insérés par l’administrateur du groupe (cad que leur OWNER doit être l’admin du groupe)
    • les utilisateurs d’un group confinés ne sont listés que pour les membres du groupe
    • on insère désormais un group en fournissant l’admin comme ceci:
      $> xwsendusergroup MyGroupLabel theGroupAdminLogin theGroupAdminPassword theGroupAdminEmail
      
      Un groupe non confiné fonctionne comme dans les versiosn précédentes.

    • Cette version introduit un système de versionning. Tous les messages (requêtes, réponses) sont maintenant encapsulés dans un élément racine ...
      De telle manière que la version soit maintenant incluse dans le protocole.
      Des champs ont été modifiés/renommés/ajoutés/retirés dans cette version : les objects ont tous les champs OWNERUID and ACCESSRIGHTS. Certains avec un champ CLIENTUID or USERUID qui ont été renomés OWNERUID.

      Bien sûr, les versions précédentes ne peuvent pas connaitre ces changements. A partir de cette versions 5.8.0 le protocole sait tenir compte de la version des clients/workers. S’ils envoient un message sans l’element XML xwhep c’est qu’ils tournent une version plus ancienne que la 5.8.0 et le serveur retrourne alors un réponse compatible.

• 20 décembre 2009 : XWHEP 5.7.7
  • Corrections
    1. workpoolsize est forcé à 1 suite à des problèmes de concurrence d’accès avec une valeur supérieure
    2. un bug corrigé dans Executor streams
    3. un bug corrigé dans la gestion des tâches perdues
  • Nouvelle fonctionnalité
    • -AUCUNE-

• 1er décembre 2009 : XWHEP 5.7.6
  • Corrections
    1. communications TCP : un bug résolue au niveau de la reconnection suite à une erreur réseau
    2. XWHEP 5.7.5 a introduit la notion de limite dans le nombre d’entrées du niveau du cache (à 10K entrées), mais l’implémentation était buggée : elle a été corrigée. Le cache gère désormais ses entrées en utilisant le mode LRU (least recently used)
    3. serveur : la détection des tâches perdues se faisaient toutes les 15s, ce qui n’est absolument pas nécessaire; cette nouvelle version effectue la vérification toutes les ALIVETIMEOUT minutes (default : 5mn).
    4. un bug corrigé dans l’access logger : il n’ouvre maintenant qu’un seul fichier et non un par thread.
    5. xtremweb.gmond.pl a été corrigé et “scale” mieux
    6. les certificats n’ont plus de dates de fin (pour faciliter le déploiement)
    7. xwconfigure corrigé : la génération des fichiers de configuration a été améliorée
    8. installeurs linux corrigés
    9. les scripts ont été corrigés : l’usage de “type” a été amélioré
    10. le scheduler rafraichit sa liste des tâches avec les PENDING seulement
  • Nouvelle fonctionnalité
    • -AUCUNE-

• 15 octobre 2009 : XWHEP 5.7.5
  • Corrections
    1. Launcher corrigé : il ne démarre plus si la clé SSL est incorrecte ou si l’URL est malformé.
    2. La gestion des paths a été corrigé dans le Launcher
    3. les messages d’erreur du worker sont plus détaillés.
    4. le worker a été corrigé: en cas de problème réseau au moment où le worker envoyait un résultat, le résultat était perdu et le worker n’etait plus capable de redemander un nouveau job.
    5. gestion des paths améliorée dans xwconfigure
    6. xwhep.bridge.pl modifié : il peut désormais se connecter directement à MySQL et n’est donc plus oblige d’utiliser le client XWHEP (on espère un gain de performances)
    7. xtremweb.gmond.pl : connexions MySQL corrigées
    8. un bug résolu au niveau du serveur : les connexions MySQL étaient mal fermées; on pouvait se retrouver avec énormément de sockets en TIME_WAIT
    9. un bug résolu dans la librairie E/S : tous les handlers sont maintenant correctement fermés en cas d’erreur/exception
    10. un bug résolu dans le cache : il ne peut plus contenir plus de 10k entrées
    11. les scripts ont été glabalement corrigés : il est préférable d’utiliser ‘type’ et non ‘which’ dans les scripts bash/sh
    12. du côté du client, xwchmod accepte aussi les UID (et pas seulement les URI)
    13. build corrigé : il génère correctement la version x86_64
    14. on n’utilise plus String.intern() parce que cela peut générer des exceptions “OutOfMemory in PermGen” (Cf http://www.codeinstructions.com/2009/01/busting-javalangstringintern-myths.html)
    15. les utilisateurs admin et worker public ne sont plus inséré dans aucun groupe (parce que ca n’était pas utilisé et pouvait porter à confusion)
  • Nouvelles fonctionnalités
    aucune

• 31 juillet 2009 : XWHEP 5.7.4
  • Corrections
    1. enregistrement des workers améliorée : on garde la version des workers
    2. un bug corrigé dans l’ordonnanceur : il ne parcourait pas la liste complete des tâches
    3. des bugs résolus dans xtremweb.ganglia :
       • les process “forkés” terminent maintenant correctement;
       • utilisation du champ “isdeleted” dans les tables DB
    4. xwhep.bridge.pl corrigé et légèrement modifié : n’est plus considéré comme erreur le fait qu’un pilot job n’execute pas de tâche (Cf XWHEP-5.7.2, point 8)
    5. des bugs corrigés dans le worker Win32 dans l’utilisation des paths et de l’option java -Xrs (Cf http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html)
    6. un bug corrigé dans le launcher : il ne doit pas effacer les JAR de mise à jour
  • Nouvelles fonctionnalités
    1. des scripts SQL pour vérifier l’état de la plate-forme à travers la DB
    2. des scripts pour upgrader la DB
• 9 juillet 2009 : XWHEP 5.7.3
  • Corrections
    1. un bug corrigé dans la définition de la base de données
       • la longueur des champs et “hosts.natedipaddr” sont maintenant 50 (et non 20) pour permettre de stocker des adresses IP V6
       • introduction d’une nouvelle table “Version” qui contient l’historique des version installées
       • un nouveau champ “hosts.pilotjob” permet de déterminer si un worker s’exécute sur une ressource de type SG (ex : EGEE)
       • le script xwsetupdb.sql modifie les tables en conséquence
       • le script xwconfigure modifie les tables de manière non destructive
    2. un bug corrigé dans la génération des dates sotckées dans la base de données (date d’insertion, date de completion etc.)
• 17 juin 2009 : XWHEP 5.7.2
  • Corrections
    1. un bug corrigé dans le bridge
    2. les installeurs Linux RPM et DEBIAN, ainsi que Mac OS X écrivent désormais leurs logs dans le répertoire /var/log
    3. la gestion des variables de configuration a été améliorée
    4. la variable KeyStore n’était pas correctement initialisée; elle peut désormais être indiferemment lue du fichier de configuration ou du paramètre Java -Djavax.net.ssl.keyStore
    5. un bug a été corrigé dans la gestion des erreurs MySQL
    6. l’utilisation des groupes de job a été corrigée
    7. un bug a été corrigé au niveau de l’ordonnanceur
    8. l’utilisation des certificats X509 a été modifiée conformément aux décisions prises par EDGeS.
       Le client vérifie maintenant automatiquement le contenu de la variable d’environnement $X509_USER_PROXY; le paramètre “–xwcert” n’est donc plus nécessaire
       En utilisant “–xwcert”, le certificat doit être valide, à défaut de quoi le job n’est pas soumis.
       Si le certificat décrit par $X509_USER_PROXY n’est pas valide, le job est soumis sans certificat. Tout worker, même s’il n’est pas un Pilot Job sur EGEE, peut désormais exécuter un job, même s’il a été soumis avec un certificat.
       Les Pilot Jobs sont des workers privés et peuvent donc exécuter tout job du propriétaire du certificat.

       Les workers (même les Pilot Job soumis sur EGEE) ne téléchargent jamais de certificat X509.
       Seul le bridge télécharge les certificats pour soumettre les pilot Job sur EGEE.

    9. Un bug a été corrigé dans la gestion des handlers de communications (ce qui a permis d’intégrer ADICS)
  • Nouvelle fonctionnalité
    1. XWHEP intègre le protocole ADICS de l’Université de Cardiff.
       Cf http://www.p2p-adics.org.
       Ceci est donc une nouvelle fonctionnalité “externe” :
       • l’intégration de nouveau protocoles dans XWHEP existe en effet depuis longtemps
       • nous restons donc dans la branche 5.7.x
• 25 mai 2009 : XWHEP 5.7.1
  • Note : cette version est nommée 5.7.1 et non 5.6.4 parce que la version 5.6.3 a introduit une nouvelle fonctionnalité et aurait du être nommée 5.7.0.
    Je corrige donc cette erreur de versionning ici.

  • Corrections
    1. xwconfigure boucle désormais jusqu’à ce que l’utilisateur donne une valeur correcte.
    2. La création des fichiers archives a été corrigée:
       *ps les fichiers *PS étaient exclus de l’archive ce qui excluaient "xwapps", "xwgroups" etc.

    3. les scripts du worker pour Mac OS X ont été corrigés
    4. les installeurs pour Mac OS X ont été corrigés. Les erreurs étaient dues à l’utilisation de NetInfo qui n’est plus supporté depuis Mac OS 10.5. NetInfo est maintenant remplacé par Directory Service qui est compatible 10.4 et 10.5. Nous avons testé 10.4.11 et 10.5.7.
    5. la gestion des paths a été corrigé sous Win32
    6. les projets Win32 innoSetup ont été corrigés
• 7 mai 2009 : XWHEP 5.6.3
  • Corrections
    1. Afin d’éviter d’éventuelles confusions entre XtremWeb et XWHEP, ce dernier installe désormais ses paquets dans /opt/XWHEP-server, /opt/XWHEP-worker and /opt/XWHEP-bridge. Les paquets XWHEP (Debian, RedHat, Apple) installent les paquets XWHEP-quelquechose et non plus xtremweb-quelquechose. Les fichiers qui existaient avant cette release (les scripts, les fichiers de configuration etc.) gardent leur “ancien” nom (xtremweb.quelquechose) pour ne pas perturber ceux qui ont déjà développé avec XWHEP.
    2. les timeout des sockets est nul par défaut
    3. HTTPLauncher, qui télécharge automatiquement la dernière version du middlewareavant de démarrer le worker a été corrigé : il utilise maintenatn le fichier le plus récent présent sur le disque local; il s’arrête immédiatement s’il ne peut accéder au disque local; l’utilisation de l’option java “-server” aété corrigée.
    4. des “deadlocks” ont été corrigé, au niveau du server.
    5. un bug a été corrigé au niveau de la gestion des noms des applications
    6. le worker garde maintenant son UID afin d’éviter de remplir inutilement la DB du server
    7. les installeurs ont été corrigés (RPM, DPKG, Apple PKG)
  • Nouvelle fonctionnalité
    1. le worker peut maintenant prendre en charge des applications et leurs librairies dynamtiques

• Mar 26, 2009 : XWHEP 5.6.2
  • un bug a été résolu au niveau de l’utilisation des URI.

• 12 mars 2009 : XWHEP 5.6.1
  • la distribution binaire a été corrigée et augmentée; elle prépare les paquets RPM, Debian et Apple pour le serveur, le worker et le client;
  • un bug corrigé au niveau du client quant à l’envoi des fichiers associés aux jobs.

• 16 février 2009 : XWHEP 5.6.0
  • cette version règle le problème de la mise à jour de la plate-forme en réintroduisant le launcher;
  • cette version est la première à fournir un paquet "binaire".

• 4 février 2009 : XWHEP 5.5.0
  • un bug a été résolu au niveau du serveur : la consommation mémoire a été améliorée.

  Les deux figures montrent la quantité de mémoire utilisée par le serveur. La 1ere figure montre une voracité croissante avec la version 5.4.0: après quatre jours, la quantité de mémoire allouée s’élève à 382Mb. La 2nde figure montre une consommation plus raisonnable avec la version 5.5.0: après six jours, la quantité de mémoire allouée est trois fois moins importante.

  
  
  

• 14 janvier 2009 : XWHEP 5.4.0
  • un bug a été corrigé au niveau de la couche des entrées/sorties

• 16 décembre 2008 : XWHEP 5.3.0
  • au niveau du serveur, les dates des évènements sont maintenant correctes (date de soumission, date d’exécution, date de résultats…)
  • un bug a été corrigé au niveau du bridge.

• 4 décembre 2008 : XWHEP 5.2.0
  • dans le serveur, un bug a été corrigé au niveau des communications; le serveur de communication ne se fige plus.

• 1er décembre 2008 : XWHEP 5.1.0
  • le bridge envoit désormais un signal au serveur à des fins de monitoring;
  • un nouveau script xtremweb.jra2 permet de monitorer un ensemble de serveurs XWHEP installés; ce script a été spécialement développé pour le JRA2 de EDGeS;
  • dans le serveur, un bug a été corrigé au niveau des communications; il semblerait que la gestion des méthodes synchronisées soit dépendant de la JVM utilisée;
  • les scripts de lancements des différentes commandes du client ont été nettoyés;
  • la page de configuration du worker peut être utilisée pour gérer un parc local de workers.

• 21 novembre 2008 :
  • La passerelle EDGeS de XWHEP à EGEE permettant l’utilisation de ressources EGEE est operationnelle; elle peut être monitorée ici.

  

• 17 novembre 2008 : XWHEP 5.0.0
  • le serveur gère désormais un pool de connexions afin d’en gérer jusqu’à 500 simultanément; s’il y en a plus, elles sont mises en attente. Ceci permet d’éviter d’éventuels manques de mémoire;
  • le client admet une nouvelle option –xwxml : elle permet de fournir un fichier XML en entrée;
  • la couche de communication a été simplifiée : il n’y a plus qu’un seul message send pour tous les types d’object;
  • le bridge a été stabilisié.

• 16 octobre 2008 : XWHEP 4.1.0
  • un bug corrigé au niveau du worker relatif à la préparation du répertoire de travail des jobs.

• 15 octobre 2008 : XWHEP 4.0.0
  • les clients peuvent maintenant se connecter à plusieurs serveurs; pour cela:
    • le client ne contient plus de passphrase et n’essaie plus de coder les mots de passe;
    • les mots de passe ne sont donc plus codés dans le fichier de config, ni que dans la base de données;
    • ceci n’introduit pas de trou de sécurité car les communications sont cryptées; il est de la responsabilité de l’utilisateur d’assurer l’intégrité de son fichier de config;
    • pour finir, ceci allège la compilation et l’installation qui n’a plus besoin de SQL.
  • un bug a été corrigé au niveau du worker dans le téléchargement des donnéees;
  • les notions de groupes et de sessions de jobs ont été réintroduites.
    Les groupes et les sessions permettent d’aggréger un ensemble de jobs.
    La seule différence réside en ce que les sessions sont automatiquement détruites quand le client se déconnecte (il se déconnecte en s’arrêtant ou quand change d’utilisateur);

  • la GUI du client ne permet plus la selection de plusieurs lignes (par ex pour effacer les lignes ou pour télécharger les résultats). Ceci est du à un bug dans le table sorter. Cette erreur sera corrigé en portant notre logiciel sous Java 6 qui introduit des table sorter natifs;
  • notre package est maintenant compatble Java 6 sans en utiliser les nouveautés (voir ci dessus); il est aussi compatible 64 bits.

• 25 septembre 2008 : XWHEP 3.1.0
  • dans le fichier de configuration, SSLKeyStore peut maintenant être un chemin relatif;
  • les propriétaires des ressources volontaires peuvent configurer leur worker en ouvrant la page http://localhost:4324;
  • la gestion du cache a été améliorée et légèrement modifée :
    • de manière générale les informations présentes dans le cache ne sont pas retéléchargées depuis le serveur; à trois exception près : les works, tasks et hosts qui sont toujours rechargés depuis le server, car ce sont des informations susceptibles de changer souvent;
    • le client garde son cache entre deux exécutions. Une nouvelle commande xwclean permet de nettoyer le cache local; cette commande est disponible dans le menu Comm de la GUI.
    • le worker efface toute trace du disque local avant de s’arreter; il ne garde donc pas de cache entre deux exécutions;
  • un bug a été résolu au niveau du serveur : la consommation mémoire a été améliorée.

  Le fichier JAR est disponible. Pour mettre à jour, vous devez:

  • copier le fichier JAR dans le répertoire lib et redémarrer votre serveur;
  • copier le fichier JAR à l’endroit défini par la variable launcher.url, dans le fichier de configuration du worker; les workers le téléchargeront automatiquement à leur prochain lancement.

  Les deux figures montrent la quantité de mémoire utilisée par le serveur. La 1ere figure montre une voracité croissante: après seulement 1H30, la quantité de mémoire allouée s’élève déjà à 78Mb. La 2nde figure montre une bonne stabilité: après plus de deux heures, la quantité de mémoire allouée n’a pas bougé de son niveau initial de 31Mb.

  
  

• 10 septembre 2008 : XWHEP 3.0.0
  • utilisation des proxy de certificat X509 pour l’utilisation de ressources de grilles institutionnelles;
  • la synchronisation a été améliorée : tout message attend maintenant une réponse du serveur;
  • la dégradation des performances constatée au niveau du serveur a été corrigée.

  Les deux figures montrent la réception de 1000 soumissions par le serveur. La 1ere figure montre clairement une dégradation des performances; elle disparait dans la 2nde figure avec les corrections.
  Le temps total d’exécution est 2.5 fois supérieur car les messages attendent maintenant tous une réponse du serveur : ceci améliore la cohérence de la plate-forme.
  
  

   

• 1er septembre 2008 : XWHEP 2.1.0
  • l’ordonnancement des tâches a été modifié afin d’ameliorer les performances. Ce n’est plus du simple round-robin: l’ordonnanceur fouille la liste des tâches en attente afin d’essayer de trouver un qui corresponde à la demande du worker;
  • le script de test a été modifié : il soumit aussi des tâches de groupes.

  La commande SQL suivante permet de mieux voir les résultats
  
select apps.name as app,label,
hex(works.accessrights),hex(apps.accessrights),
works.status,users.login as worker_login,
users.rights as worker_level
from
works,apps,tasks,hosts,users
where
works.appuid=apps.uid and
works.uid=tasks.uid and
tasks.hostuid=hosts.uid and
hosts.owneruid=users.uid
order by works.label;


  On voit que le worker public (dont le login est worker) n’a pris en charge que des jobs publics (dont le label est public…); les workers privés (dont les logins sont user…) n’ont pris en charge que les jobs leur appartenant (dont les labels finissent par leur login).

  “

   

• 29 août 2008 : XWHEP 2.0.0
  • des bugs résolus dans la gestion du cache;
  • des bugs résolus au niveau du serveur dans la gestion des utilisateurs et des applications;
  • des bugs résolus dans la GUI du client;
  • des bugs résolus dans l’utilisation de la clé électronique du serveur.

   

  Le server est désormais certifié par une clé autosignée générée par createKeys. La prochaine version permettra d’utiliser des certificats X.509 certifiés par une CA.

  Pour installer cette version, il est nécessaire de réinstaller la base de données.

  L’installation et le déploiement nécessitent les actions suivantes dans cet ordre précis (createKeys doit être exécuté avant install).
  
$> make removeDB
$> make installDB
$> make clean
$> make
$> make createKeys
$> make install


  Pour un déploiement de production, les clés ne doivent être générées qu’une seule fois; la regénération des clés nécessite un redéploiement complet de la plate-forme.

  L’utilisation de SSL a un coût en termes de communication dans un rapport de un à deux. La figure de gauche montre le nombre de paquets TCP sans utiliser SSL; la figure de droite montre le nombre de paquets TCP pour la même commande en utilisant SSL :

  
  

   

  Un script de test de la plate-forme est fourni dans le répertoire bin de l’installation
  
$> xtremweb.tests.pl


  L’utilisation de ce script nécessite les droits administateur au niveau de la plate-forme (le fichier de config crée à l’installation poossède ces droits).

  Ce script éxecute les commandes suivantes:

  • insertion d’une application publique
  • insertion de deux groupes d’utilisateur
  • insertion 6 nouveaux utilisateurs : deux utilisateurs par groupe et deux utilisateurs hors de tout groupe
  • insertion d’une application privée par utilisateur
  • insertion de 12 jobs : un job public et un job privé par utilisateur
  • lancement de workers
  • monitoring des jobs

  A la fin du script, nous pouvons constater que tous les jobs sont COMPLETED. On peut vérifier la bonne exécution du test avec la commande SQL suivante (nous ne pouvons utiliser le client pour cette vérification, car il n’affiche pas l’identité des workers dans la liste des jobs) :
  
select works.status,works.label,hosts.name,users.login
from users,works,tasks,hosts
where tasks.uid=works.uid
and tasks.hostuid=hosts.uid and
hosts.owneruid=users.uid
order by users.login;


  La figure suivante montre le résultat de l’auto test.

  On voit que le worker public (dont le login est worker) n’a pris en charge que des jobs publics (dont le label est public…); les workers privés (dont les logins sont user…) n’ont pris en charge que les jobs leur appartenant (dont les labels finissent par leur login).

  “

   

• 30 juillet 2008 vous pouvez télécharger le projet de déploiement MSDev
• 24 juillet 2008 : XWHEP 1.2.0

  Un bug a été résolu dans le worker, au niveau de la gestion de l’entrée standard (stdin) de l’application utilisateur.

  Il reste toutefois un problème non résolu si cette application tente de tester la disponibilité de données dans stdin. Il y a alors une grande chance que la plate-forme n’ai pas eu le temps de positionner correctement stdin.

  Ce problème est du au language Java utilisé pour développer notre plate-forme.

  L’application utilisateur ne doit donc pas tester la disponibilité de données sur stdin, mais se contenter de le lire. Dans le cas où stdin est optionnel, il faut alors modifier l’application afin qu’elle prenne ses éventuelles données depuis un fichier texte.

  Exemple:

  L’exemple suivant marche correctement si myApp ne teste pas stdin:

  
$> myApp < aFile


  Si stdin est optionnel, il faut modifier l’application afin de lui fournir ces données optionnelles depuis un fichier texte; par exemple:

  
$> myApp -f aFile


  Désolé pour les inconvénients.

   

• 21 juillet 2008 : XWHEP 1.1.0
  • introduction de la gestion des proxy de certificat X.509
  • un bug a été résolu au niveau du téléchargement des données.

  Pour installer cette version, il est nécessaire de réinstaller la base de données
  
$> make removeDB
$> make installDB
$> make install


   

• 17 juillet 2008 : XWHEP 1.0.31
  • un bug résolu au niveau du worker dans la gestion des erreurs
  • un bug résolu au niveau des entrées/sorties
  • la page HTML du worker est maintenant configurable
  • les performances ont été améliorées dans un rapport de 1 à 14 grâce à une meilleure utilisation des caches

    Les graphes ci dessous montrent deux soummissions de 1000 jobs. Nous voyons que la résolution du bug des E/S et l’utilisation du cache permettent de faire quatre fois moins d’appels internes pour un temps d’exécution 14 fois plus rapide.

    
    

• 19 juin 2008 : XWHEP 1.0.30

  Un bug majeur résolu au niveau du serveur dans la gestion des tâches

• 22 mai 2008 : XWHEP 1.0.29

  Trois bugs corrigés

  • l’output config quand on insere un nouveau user;
  • le téléchargement des tasks;
  • l’URI des datas.
• 7 mai 2008 : XWHEP 1.0.28

  Du nettoyage mineur

• 28 avril 2008 : la version 1.0.27 a été testée avec succès sur Grid5000 : 12000 jobs exécutés sur 200 workers
• 25 avril 2008 : XWHEP 1.0.27

  Un bug a été résolu dans le protocole de stockage des résultats.

• 23 avril 2008 : XWHEP 1.0.26

  Un bug a été résolu au niveau du client, dans la soumission des données.

• 17 avril 2008 : XWHEP 1.0.25

  Un bug a été résolu au niveau de l’accès à la base de données.

• 15 avril 2008 : XWHEP 1.0.24

  Nous n’utilisons plus log4j, car nous suspectons des fuites de mémoires.

• 8 avril 2008 : XWHEP 1.0.23

  Un bug résolu au niveau de l’upload des résultats par le worker.

• 4 avril 2008 : XWHEP 1.0.22

  Un bug résolu au niveau des communications.

• 3 avril 2008 : XWHEP 1.0.21

  Un bug résolu au niveau du worker.

• 2 avril 2008 : XWHEP 1.0.20

  Le client récupère correctement les résultats.

• 1 avril 2008 : XWHEP 1.0.19

  Lors de la soumission, on peut maintenant fournir directement un fichier d’environnement; le client crée automatiquement la donnée correspondante.

• 17 mars 2008 : un bug sur les délais de communication a été résolu.
• 20 février 2008 : les communications HTTP contiennent un bug en cours de résolution; les communications TCP sont donc les communications par défaut pour le moment.
• 7 février 2008 : deux bugs ont été résolus :
  • synchronisation inter threads au niveau du serveur;
  • résolution des IP publiques/privées.
• 25 janvier 2008 : l’ordonnanceur fonctionne maintenant correctement; il tient compte des applications et des workers publics, de groupe ou privés:
  • le worker public possède les droits d’utilisateur "WORKER_USER"; il ne peut prendre en charge que des jobs publics (des jobs dont les droits d’accès contiennent o+rx);
  • le worker de groupe est un worker public (droit utilisateur "WORKER_USER") inséré dans un groupe; il ne peut prendre en charge que des jobs du groupe (des job dont les droits d’accès contiennent g+rx);
  • le worker privé est worker non public (qui n’a pas les droits utilisateurs "WORKER_USER") et ne peut prendre en charge que les jobs de son propre utilisateur (des jobs dont les droits d’accès contiennent u+rx)
• 16 janvier 2008 : un bug a été résolu au niveau client;
• 11 janvier 2008 : un bug a été résolu au niveau de la base de données;
• 8 janvier 2008 : les installers fonctionnent correctement; des bugs ont été résolus au niveau du client;
• 21 décembre 2007 : Le middleware fonctionne correctement; des tests plus approfondis sont en cours;
• 26 novembre 2007 : Le middleware est en tests finaux.