[vmchecker-dev] [USO/RL][RSoC2010] Integrare USO/RL în vmchecker (and more)

Tue May 18 18:58:01 EEST 2010

2010/5/18 Lucian Adrian Grijincu <lucian.grijincu at gmail.com>

> 2010/5/17 Calin Iorgulescu <calin.iorgulescu at gmail.com>:
> > Ca primă idee mă gândeam ca studenții să aibă posibilitatea să urce prin
> > vmchecker MD5-ul arhivei cu mașina virtuală pe care a fost rezolvată
> tema,
> > arhiva urmând să fie urcată pe un server ales de noi ulterior. Astfel pe
> git
> > să fie puse doar fișierele MD5, nu întregile arhive.
>
>
> Nu văd nicio valoare în MD5.
> Pot să pună un document cu calea către mașina virtuală corespunzătoare.
>
>
Utilitatea sumei MD5 apare atunci când cineva termină tema la timp dar din
varii motive (deobicei net prost sau faptul că nu a anticipat clar cât
durează urcarea arhivei) nu a putut pune arhiva la timp. Un astfel de
scenariu este mult prea des întâlnit (mai ales de cei care stau în regie).
Suma MD5, practic, este cea care stabilește faptul că tema a fost terminată
la timp.

> > În momentul în care
> > arhiva este urcată, studentul să aibă posibilitatea de a lansa spre
> > evaluarea acea mașină, alegând-o dintr-o listă de fișiere din home-ul său
> de
> > pe server (credtis to VladD for the ideea).
>
> Mai greu de implementat partea asta: trebuie modificată interfața web
> și făcut ceva special-purpose pentru vmchecker-uso.
>
>
> > Pentru a evita abuzurile, mă
> > gândesc fiecare student să aibă o limită de 3 submit-uri, după care
> pentru
> > alte submit-uri să contacteze echipa.
>
> Dacă prin submituri te referi la uploadul de fișiere prin interfața
> web, chestia asta se poate face foarte ușor în vmchecker.
> Dacă te referi la limitarea de urcări de mașini virtuale, aici nu știu
> cât de ușor e.
>
>
> Pe mașina de storage, studenții se autentifică prin LDAP (în loc de
> /etc/passwd + /etc/shaddow). Fiecare are un $HOME și o cotă.
> Drepturile sunt 0700 ca să nu se copieze.
>
> După ce studentul suie fișierul cu calea către mașina virtuală, se
> pornește procesul normal: testerul și ce a suit studentul e trimis pe
> mașina de testare.
> Queue-managerul de pe mașina virtuală primește submisia și pornește un
> commander dependent de temă -- în cazul ăsta commanderul de USO.
>
>
>
Prin submit-uri mă refer la trimiteri către verificare a temei, în sensul că
un student își trimite singur tema spre verificare (o pune în queue) atunci
când a încărcat atât MD5-ul cât și arhiva pe storage (anul acesta am folosit
uso.ncit care avea în spate un storage montat peste iSCSI).

Deci într-adevăr aici procedeul de trimitere spre verificare diferă un pic,
în sensul că studentul ar trebui să poată urca întâi MD5-ul, apoi arhiva
propriu-zisă, și apoi să dea drumul execuției (alegând din home-ul său de pe
storage arhiva corespunzătoare).
Este, într-adevăr vorba de schimbare un pic a interfeței.

>
> > Pentru evaluarea arhivei ar trebui ca aceasta să fie copiată de pe
> > storage-ul ales, despachetată și apoi înscrisă în VMWare Server, rulată,
> și
> > apoi făcută unregister. Aici ar fi util de știut exact cât de mult ar
> trebui
> > modificat vmchecker pentru a putea funcționa și pe alte mașini virtuale,
> nu
> > doar pe cea "stas".
>
> Commanderul copiază tema de unde a scris-o studentul și pornește
> testarea -- asta poate fi o problemă: copierea unei mașini de 2GB va
> dura măcar 3 minute -- testarea încă vreo două măcar: înregistrare
> mașină în vmware, bootare, inițializare interfețe, inițializare vmware
> tools *, copiere tester, rulare tester, preluare rezultate, închidere
> și ștergere mașină.
>
> Vmware tools poate prezenta o problemă: pentru a funcționa trebuie
> instalat în mașina virtuală, dar instalarea nu e un proces automant și
> nici nu poate fi făcut prin ssh (în procesul de instalare se resetează
> interfețele de rețea omorând toate conexiunile ssh). O soluție e să
> obligați studenții să instaleze vmware tools. Problema e (din câte
> știu -- s-ar putea să mă înșel) că orice versiune de tools nu e
> compatibilă cu orice vmware și trebuie să obligați studenții să aibă o
> acceeași versiune.
>
> Altă variantă e ca testele să se facă complet peste ssh ca vmware
> tools să nu intre în discuție. Asta presupune cunoscut username-ul și
> IP-ul unei interfețe sau numele mașinii (avahi).
>

Ar fi fost bine de optat pentru o variantă care nu include VMWare Tools
exact din motivele enumerate de tine mai sus. Desigur asta prezintă câteva
dezavantaje (dacă sistemul nu bootează sau nu are interfețele sau serverul
de SSH configurate cum trebuie nu se poate evalua), dar în acest sens vom
posta clar niște mențiuni care să explice faptul că o arhivă nefuncțională
trimisă nu va primi punctaj.

Dimensiunea unei arhive la USO este ~300-400 MB arhivată iar la RL poate
ajunge pe la 1GB (if my memory serves). Însă, dacă storage-ul este tot un
share similar iSCSI care este simultan montat pe mașinile care vor face
evaluarea, timpul va fi redus foarte mult eliminând overhead-ul unui scp
(asta poate fi aplicat și pt. celelalte teme, nu doar USO/RL, deși acolo
sursele sunt prea mici ca să conteze această diferență).

>
>
> > Ca o a doua parte, în funcție de timp/resurse/apreciere, ar fi
> posibilitatea
> > de a avea în spate mai multe mașini cu VMWare Server pe care să se
> evalueze
> > temele "distribuit". Un sistem de acest tip, doar că barbar, a fost
> folosit
> > anul acesta pentru corectare, împărțirea arhivelor făcându-se manual
> (Ex.:
> > stația 1: a-l, stația 2: m-s etc.). Acest lucru ar ușura și ar face mult
> mai
> > rapidă corectarea temelor.
>
> Asta se poate face destul de ușor: se definesc o serie de mașini de
> testare și interfața web trimite pe varii mașini la testare.
>
>
> > Aș fi vrut opinia voastră în sensul cât de utilă/fezabilă este această
> idee.
> > So, what say you?
>
>
> Se poate face, problema e că trebuie modificat destul cod pentru a
> suporta toate treburile astea.
> Eu o să fiu foarte ocupat cu GSoC la vară și nu voi fi prea mult
> disponibil, de asta n-am înscris vmchecker la RSoC -- niciunul din
> dezvoltatorii vmchecker nu este disponibil în vara asta.
>
> Oricum codul a fost îmbunătățit mult anul ăsta și e mult mai ușor de
> lucrat cu el.
> Partea de backend (python) e 30% comentarii.
>
> Dacă vrei să lucrezi pe vmchecker putem să ne întâlnim să discutăm mai
> detaliat.
>

Mulțumesc mult pentru răspuns și lămuriri, chiar mă interesează proiectul.
Vis-a-vis de o întâlnire, RD zicea că ar vrea să stabilim o întâlnire în
acest sens.
@Răzvan: crezi că am putea fixa o întâlnire să discutăm ?

>
> --
>  .
> ..: Lucian
> _______________________________________________
> vmchecker-dev mailing list
> vmchecker-dev at lists.rosedu.org
> http://lists.rosedu.org/listinfo/vmchecker-dev
>

Călin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rosedu.org/pipermail/vmchecker-dev/attachments/20100518/be920688/attachment-0001.htm>