View source for BigGrid virtualisatie/notulen 20090706

== Agenda ==
# Introductie
#* Terugblik op [http://indico.cern.ch/conferenceDisplay.py?confId=56353 CERN workshop]
# Verzamelen Use Cases.
#* Welke vakgebieden?
#* Hoe (methode)?
#* Wie (mensen)?
# Externe initiatieven
#* Virtualisatie (CERNVM, KVM, VMWare, Xen).
#* Cloud computing (Nimbus, Eucalyptus, OpenNebula).
#* Cloud/Grid integratie (Desy, Karlsruhe, INFN, CERN-VMO).
# Security and Operations
#* Public versus private network.
#* Classificatie van Virtual Machines.
# AOB
#* Volgende vergadering

== Notulen ==
;Datum: 6 juli 2009
;Aanwezig: Marc (MvD), Pieter (PvB), Floris (FS), Ronald (RS), Sander (SK)
;Afgemeld: Ron (RT)

Sander doet verslag van de virtualisatie-workshop bij CERN d.d. 24–26 juli. In dit verslag komen de volgende zaken aan de orde:
# SK: Het idee dat VMs voor extra veiligheid zorgen omdat de gebruikers binnen een VM 'gevangen zitten' was volgens sommige aanwezigen naïef: VMs zouden extra security risks veroorzaken omdat er veel relatief nieuwe software wordt geintroduceerd (hypervisor, network bridges, paravirtual drivers, VM management, etc.) met bijkomende exploits.
# SK: Bij het gebruik van VMs op de worker nodes kan onderscheid worden gemaakt tussen drie categorieen.
#;Class 1: site generated VMs, trusted by site
#;Class 2: VO generated VMs, trust based on certification and policy
#;Class 3: User generated VMs, untrusted
# SK: Het managen en schedulen van VMs is gecompliceerd.
#* De beheerders op de CERN workshop wilden kunnen kiezen uit verschillende soorten VMs. Hoe worden die beheerd?
#* Het CERN wil dat het schedulen van VMs geintegreerd is met de huidige job scheduling.
# PvB: er waren bij CERN uitsluitend HEP-gebruikers; de belangen van niet-HEP gebruikers niet zijn meegenomen. SK: ontkent dit

Tijdens de discussie over de scope van de werkgroep werden een aantal punten gemaakt.
* SK+RS: Het Nikhef ziet voordeel in het gebruik van Class 1 VMs maar heeft ernstige twijfels over Class 2 en 3 VMs. Er is een IP adres probleem voor Class 1 dat moet worden opgelost als het aantal adressen met ongeveer een factor 10 toeneemt (NAT/private addresses). Er zijn policy en security issues die moeten worden opgelost voordat het gebruik van Class 2 en/of 3 kan worden toegestaan.
* SK: HEP heeft voorkeur voor het gebruik van Class 2 VMs. Ten eerste omdat HEP VOs vaak gemeenschappelijke software draaien, die prima in een VO generated VM beschikbaar kan worden gemaakt. Ten tweede omdat ze de kans groter achten voor Class 2 VMs dat oplossingen kunnen worden gevonden voor de policy en security issues dan voor Class 3 VMs.
* MvD+PvB+FS: niet-HEP heeft voorkeur voor het gebruik van Class 3 VMs; er is voor hun geen winst in het gebruik van Class 1 of Class 2 VMs. Individuele gebruikers draaien allemaal hun eigen software op verschillende platforms en willen de mogelijkheid hebben om die specifieke combinaties te gebruiken op de sites. Zij geven aan dat het nog onduidelijk is of policy en security issues echt gecompliceerder zijn voor Class 3 VMs.
* PvB: Uitgangspunt moet zijn wat nuttig is voor gebruikers. Indien nodig moeten security policies en wetten daarop worden aangepast.
* MvD+PvB: Binnen het kader van BigGrid gaat het erom dat we iets goeds maken voor eindgebruikers. Class 1 VMs zijn een interne beheers-aangelegenheid; sites kunnen zelf beslissen of ze hun gLite WN's in fysieke of virtuele machines draaien. Dat valt buiten de scope van BigGrid, of in ieder geval van deze werkgroep. Het interessants voor gebruikers is duidelijk de Class 3 VM, en dat is waar we ons op moeten richten.
* PvB: Class 2 VM's zijn buiten HEP niet "viable": De niet-HEP VO's zijn puur administratieve entiteiten, zonder de resources om, in overleg met sites en gebruikers, VMs te bouwen en te laten certificeren. PvB betwijfelt zelfs dat dit voor HEP-VO's een werkbare oplossing is.

Er volgt een technische discussie over het schedulen van de VMs.
* PvB heeft voorkeur voor een systeem waarbij het opstarten van VMs en het draaien van gLite jobs verschillende dingen zijn: nieuwe, non-HEP gebruikers kunnen via een Amazon-achtige web-interface (en RESTful web-service) VMs draaien op het Grid. Legacy gebruikers (HEP) kunnen jobs blijven inschieten in de gLite WMS. De WMS zal dan, indien nodig, gLite workernode VMs opstarten op het Grid (via bovengenoemde aparte interface) en vervolgens op die gLite nodes de jobs doen uitvoeren.
* SK: er zijn al implementaties (Haizea) die via de huidige scheduler de mogelijkheid bieden om VMs te schedulen zonder het draaien van een job, de user interface zal dan echter niet veranderen. Ook zijn er mogelijkheden (DESY/INFN) om jobs automatisch in VMs te laten draaien. Dat laatste mechanisme voldoet echter niet aan de gewenste scheiding tussen VMs en jobs.

Om vooruitgang te boeken zijn de volgende actiepunten gedefinieerd.
* Sander maakt een concreet scenario voor het gebruik van Class 2 VMs bij Nikhef. Daaruit moet kunnen worden opgemaakt welke wijzigingen nodig zijn in het huidige systeem om Class 2 VMs te ondersteunen.
* Pieter doet hetzelfde voor Class 3 VMs.
* Ronald maakt een overzicht van alle policy en security issues die de site heeft met Class 2 en 3 VMs. Daarbij verdienen twee argumenten bijzondere aandacht:
*# Waarom kan het bij Amazon wel en bij ons niet?
*# Waarom geldt een argument wel voor VMs en niet voor 'normale' jobs?

;Volgende vergadering: dinsdag 18 augustus 15:00 -- Floris zal ook weer aanwezig zijn

[[Category:BiGGrid / Agendas and Minutes]]