<br><br><div class="gmail_quote">2010/5/18 Lucian Adrian Grijincu <span dir="ltr"><<a href="mailto:lucian.grijincu@gmail.com">lucian.grijincu@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2010/5/17 Calin Iorgulescu <<a href="mailto:calin.iorgulescu@gmail.com">calin.iorgulescu@gmail.com</a>>:<br>
<div class="im">> Ca primă idee mă gândeam ca studenții să aibă posibilitatea să urce prin<br>
> vmchecker MD5-ul arhivei cu mașina virtuală pe care a fost rezolvată tema,<br>
> arhiva urmând să fie urcată pe un server ales de noi ulterior. Astfel pe git<br>
> să fie puse doar fișierele MD5, nu întregile arhive.<br>
<br>
<br>
</div>Nu văd nicio valoare în MD5.<br>
Pot să pună un document cu calea către mașina virtuală corespunzătoare.<br>
<div><br></div></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> În momentul în care<br>
> arhiva este urcată, studentul să aibă posibilitatea de a lansa spre<br>
> evaluarea acea mașină, alegând-o dintr-o listă de fișiere din home-ul său de<br>
> pe server (credtis to VladD for the ideea).<br>
<br>
</div>Mai greu de implementat partea asta: trebuie modificată interfața web<br>
și făcut ceva special-purpose pentru vmchecker-uso.<br>
<div class="im"><br>
<br>
> Pentru a evita abuzurile, mă<br>
> gândesc fiecare student să aibă o limită de 3 submit-uri, după care pentru<br>
> alte submit-uri să contacteze echipa.<br>
<br>
</div>Dacă prin submituri te referi la uploadul de fișiere prin interfața<br>
web, chestia asta se poate face foarte ușor în vmchecker.<br>
Dacă te referi la limitarea de urcări de mașini virtuale, aici nu știu<br>
cât de ușor e.<br>
<br>
<br>
Pe mașina de storage, studenții se autentifică prin LDAP (în loc de<br>
/etc/passwd + /etc/shaddow). Fiecare are un $HOME și o cotă.<br>
Drepturile sunt 0700 ca să nu se copieze.<br>
<br>
După ce studentul suie fișierul cu calea către mașina virtuală, se<br>
pornește procesul normal: testerul și ce a suit studentul e trimis pe<br>
mașina de testare.<br>
Queue-managerul de pe mașina virtuală primește submisia și pornește un<br>
commander dependent de temă -- în cazul ăsta commanderul de USO.<br>
<div class="im"><br>
<br></div></blockquote><div><br>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). <br>
<br>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). <br>
Este, într-adevăr vorba de schimbare un pic a interfeței.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
<br>
> Pentru evaluarea arhivei ar trebui ca aceasta să fie copiată de pe<br>
> storage-ul ales, despachetată și apoi înscrisă în VMWare Server, rulată, și<br>
> apoi făcută unregister. Aici ar fi util de știut exact cât de mult ar trebui<br>
> modificat vmchecker pentru a putea funcționa și pe alte mașini virtuale, nu<br>
> doar pe cea "stas".<br>
<br>
</div>Commanderul copiază tema de unde a scris-o studentul și pornește<br>
testarea -- asta poate fi o problemă: copierea unei mașini de 2GB va<br>
dura măcar 3 minute -- testarea încă vreo două măcar: înregistrare<br>
mașină în vmware, bootare, inițializare interfețe, inițializare vmware<br>
tools *, copiere tester, rulare tester, preluare rezultate, închidere<br>
și ștergere mașină.<br>
<br>
Vmware tools poate prezenta o problemă: pentru a funcționa trebuie<br>
instalat în mașina virtuală, dar instalarea nu e un proces automant și<br>
nici nu poate fi făcut prin ssh (în procesul de instalare se resetează<br>
interfețele de rețea omorând toate conexiunile ssh). O soluție e să<br>
obligați studenții să instaleze vmware tools. Problema e (din câte<br>
știu -- s-ar putea să mă înșel) că orice versiune de tools nu e<br>
compatibilă cu orice vmware și trebuie să obligați studenții să aibă o<br>
acceeași versiune.<br>
<br>
Altă variantă e ca testele să se facă complet peste ssh ca vmware<br>
tools să nu intre în discuție. Asta presupune cunoscut username-ul și<br>
IP-ul unei interfețe sau numele mașinii (avahi).<br></blockquote><div><br>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.<br>
<br>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ță).<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
<br>
> Ca o a doua parte, în funcție de timp/resurse/apreciere, ar fi posibilitatea<br>
> de a avea în spate mai multe mașini cu VMWare Server pe care să se evalueze<br>
> temele "distribuit". Un sistem de acest tip, doar că barbar, a fost folosit<br>
> anul acesta pentru corectare, împărțirea arhivelor făcându-se manual (Ex.:<br>
> stația 1: a-l, stația 2: m-s etc.). Acest lucru ar ușura și ar face mult mai<br>
> rapidă corectarea temelor.<br>
<br>
</div>Asta se poate face destul de ușor: se definesc o serie de mașini de<br>
testare și interfața web trimite pe varii mașini la testare.<br>
<div class="im"><br>
<br>
> Aș fi vrut opinia voastră în sensul cât de utilă/fezabilă este această idee.<br>
> So, what say you?<br>
<br>
<br>
</div>Se poate face, problema e că trebuie modificat destul cod pentru a<br>
suporta toate treburile astea.<br>
Eu o să fiu foarte ocupat cu GSoC la vară și nu voi fi prea mult<br>
disponibil, de asta n-am înscris vmchecker la RSoC -- niciunul din<br>
dezvoltatorii vmchecker nu este disponibil în vara asta.<br>
<br>
Oricum codul a fost îmbunătățit mult anul ăsta și e mult mai ușor de<br>
lucrat cu el.<br>
Partea de backend (python) e 30% comentarii.<br>
<br>
Dacă vrei să lucrezi pe vmchecker putem să ne întâlnim să discutăm mai detaliat.<br></blockquote><div><br>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.<br>
@Răzvan: crezi că am putea fixa o întâlnire să discutăm ?<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
--<br>
.<br>
<font color="#888888">..: Lucian<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
vmchecker-dev mailing list<br>
<a href="mailto:vmchecker-dev@lists.rosedu.org">vmchecker-dev@lists.rosedu.org</a><br>
<a href="http://lists.rosedu.org/listinfo/vmchecker-dev" target="_blank">http://lists.rosedu.org/listinfo/vmchecker-dev</a></div></div></blockquote></div><br><br>Călin<br>