XtremWeb-HEP 8
XtremWeb-HEP 8 introduit la virtualisation en permettant aux utilisateurs de soumettre leurs propres machines virtuelles
XtremWeb-HEP prend en charge les applications virtuelles
La nouvelle version de XtremWeb-HEP est un tournant majeur pour le monde des grilles de PC.
Pour la première fois, les utilisateurs peuvent soumettre leurs propres machines virtuelles sur des PC volontaires.
Grace à 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.
La documentation à été mise à jour.
- Corrections
- un bug corrigé dans l’insertion de session> ; le server doit positionner le champ owneruid si le client ne l’a pas fait
- 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
- certaines parties de code ont été réécrite plus POO
- un bug corrigé dans le client, au niveau du parser de macro
- un bug corrigé dans l’insertion de session> ; le server doit positionner le champ owneruid si le client ne l’a pas fait
- Nouvelles fonctionnalités
- n/a
- Corrections
- l’encodage est forcé à UTF-8
- un bug de synchronisation inter-thread a été corrigé au niveau du serveur
- Nouvelles fonctionnalités
- n/a
- Corrections
- 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
- Executor : un bug corrigé dans le process de nettoyage de fin d’exécution
- Web Interface v0.2 :
l’aide a été mise dans le "XtremWeb-HEP User Guide"
introduction des Web Workers
- 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)
- des bugs corrigés dans les scripts shell
- le code a été nettoyé pour une meilleur utilisation de la librarie "Jetty"
- 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
- les LiveCD sont désormais configurés comme suit
- Nouvelles fonctionnalités
- introduction du mécanisme de WALLCLOCKTIME
- introduction du status RESULTREQUEST
- introduction de la variable FORCENEWUID dans la configuration des workers, afin de faciliter le déploiement des workers sur un cloud
- les jobs peuvent maintenant être retrouvés par status
- introduction de OpenId pour faciliter l’utilisation de la platform
- l’ordonnauceur a été amélioré : il prend maintenant correctement en compte "hosts.incomingconnection" ainsi que quot ;exptedhost"
- le bridgee DG - SG est compatible avec l’application partagée "VirtualBox"
- des corrections ont été apportées concernant la registration d’application et la gestion de tâches
- les fichiers temporaires sont maintenant correctement effacés
- 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=<xwhep version="8.0.2-flyinggrid"><app name="pouet" /></xwhep>
pour retrouver les applications
https://server/getapps - un bug corrigé dans le download des données par HTTP
- SmartSocket fonctionne correctement ; les communications inter noeuds sont implémentées ; merci à Jason Maassen de Netherlands eScience Center à Amsterdam, pour son aide
- la création des live CD peut être customisée
- 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)
- un nouveau package Mac OS X : "xwhep.vworker" pour déployer le middleware dans une VM
- le server a une interface Web disponible par HTTPS
- l’ordonnanceur a été amélioré : il tien désormais compte de hosts.incomingconnection
- 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é
- le bridge DG vers SG est compatible avec les applications partagées. L’application VirtualBox peut donc être utilisée sur les ressource EGI
- la gestion des applications et des tâches ont été améliorées
- le client nettoie correctement ses fichiers temporaires
- l’interface REST a été entièrement réécrite. L’utilisateur doit avoir un ertificat X509 valide.
L’élément racine
<xwhep></xwhep>doit être utilisé
Exemple :-
https://server/sendapp/?XWPARAM=<xwhep version="8.0.2-head"><app uid="2853ae1e-3711-4412-b77f-acea8d9b54ee" name="pouet" /></xwhep>: 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
-
- 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)
- 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)
- un nouveau package OS X "xwhep.vworker" pour deployer le middleware dans une VM (typiquement pour tourner un worker dans une VM)
- un bug corrigé dans la gestion des dépassements de délai au niveau des communications : la reconnection est maintenant automatique
- le client compresse désormais les données automatiquement, si nécessaire
- les workers ne doivent pas utiliser le mode connecté introduit dans la version 7.4.0
- 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/)
- un bug corrigé dans l’utilisation des URI : les ampersand sont maintenant acceptés s’ils sont écrits sous la forme "&s;"
- un bug corrigé au niveau du client dans l’utilisation des fichiers XML (avec "—xwxml")
- dans le client, la gestion des groupes d’utilisateurs a été corrigée
- 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
- utiliation de IBIS SmartSockets pour la gestion des tunnels de communication
- une nouvelle option pour le client KEEPZIP (pour le debugging)
- 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
- 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é.
- un work peut être modifié par son propriétaire. Ceci est une demande de SpeQulOS (EDGI JRA2)
- 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)
26 février 2013 : XWHEP 8.2.0
25 juin 2012 : XWHEP 8.1.2
Nouvelles fonctionnalités
May 3rd, 2012 : XWHEP 8.0.2
Nouvelles fonctionnalités
20 février 2012 : XWHEP 8.0.1
Nouvelles fonctionnalités



oleg