<p><br>
On Jun 8, 2012 2:41 PM, "Vlad Dogaru" <<a href="mailto:ddvlad@rosedu.org">ddvlad@rosedu.org</a>> wrote:<br>
><br>
> 2012/6/7 Valentin Gosu <<a href="mailto:valentin.gosu@gmail.com">valentin.gosu@gmail.com</a>>:<br>
> > Salut,<br>
> ><br>
> > In discutiile mele cu Razvan am determinat ca modul de comunicatie intre<br>
> > storer si tester este defectuos, in principal modul cum este folosit SSH-ul.<br>
> ><br>
> > In prezent, atat pe storer cat si pe tester trebuie sa existe conturi pentru<br>
> > fiecare materie, cu chei publice generate. La trimiterea unei teme de catre<br>
> > student (la SO de exemplu), aceasta se salveaza in repo, in home-ul userului<br>
> > SO, iar bundle-ul este trimis prin SSH catre contul SO de pe tester. Acesta<br>
> > este primit de queue-manager, ce ruleaza in contextul contului SO, iar dupa<br>
> > corectare se il copiaza inapoi prin SCP, in repo-ul de pe contul SO.<br>
><br>
> E defectuos numai în situația în care maparea dintre userii de pe<br>
> storer și tester nu e 1-to-1.<br>
><br>
> Anul ăsta, pentru că avem o mașină nouă (care e o rachetă, îmi permit<br>
> să adaug), fiecare curs are propriul user pe ambele mașini.<br>
> Administratorii cursurilor în cauză pot (re)porni serviciul de<br>
> testare, după cum pot edita și detalii despre assignments.  Nu văd<br>
> ceva greșit în asta.</p>
<p>Nu era gresit, dar mi se pare un pic prea complicat sa avem un cont pentru ficare materie si pe tester. Ar fi mai simplu cum propunem noi.<br>
><br>
> Ce era greșit era abordarea de anul trecut în care, forțați de<br>
> împrejurări (no hardware), 2-3 cursuri împărțeau aceeași coadă și<br>
> aveam probleme cu cheile SSH împrăștiate peste tot.  so@elf putea<br>
> ajunge pe so@sanctuary, apoi pe so2@elf.  Problema era "rezolvată" cu<br>
> ACL-uri pe home-uri, which sucked, dar a fost rezolvată de-a binele<br>
> prin alocarea unei mașini mai țepene, care poate rula mai mult de<br>
> jumate de mașină virtuală simultan.<br>
><br>
> > Pe langa faptul ca cheile publice pun probleme la adaugarea unei noi<br>
> > materii, dorim sa reducem accesul statiei tester la fisierele de pe storer.<br>
> ><br>
> > In acest sens, propunem urmatoarele modificari:<br>
> > 1. Pe storer in contextul user-ului vmchecker sa ruleze un daemon care se<br>
> > ocupa de comunicatia cu tester-ul. Acesta trimite bundle-ul catre storer si<br>
> > este notificat cand se termina testarea, moment in care copiaza arhiva<br>
> > local.<br>
> > 2. Pe tester sa existe un singur user, in contextul caruia ruleaza masinile<br>
> > virtuale. Pe aceasta masina ruleaza un singur queue-manager care detecteaza<br>
> > existenta unui bundle nou (folosind inotify), testeaza, si notifica daemonul<br>
> > de pe storer. In acest fel, tester-ul nu are deloc acces pe storer.<br>
><br>
> Asta nu e chiar atât de diferit față de ce avem acum.  Corectează-mă<br>
> dacă greșesc, dar diferența este în faptul că nu se mai SCP-iază<br>
> rezultatele pe storer, ci storerul e notificat și și le ia singur,<br>
> right?<br>
><br>
> E o problemă cu a rula o singură coadă: <a href="http://vmchecker.cs.pub.ro">vmchecker.cs.pub.ro</a> are 8<br>
> core-uri, e o idee *bună* să avem o coadă per curs, ca să nu se<br>
> reflecte un deadline la SO2 în RTT-ul temelor de la SD, de exemplu.<br>
></p>
<p>Din cate imi dau seama din callback.py, tester-ul trimite fisierele pe storer.</p>
<p>Cat despre queue-manager, nu vad de ce acesta nu ar putea sa porneasca mai multe masini in acelasi timp. Oricum, acest neajuns o sa incerc sa il rezolv complet in etapa urmatoare a proiectului: daemonul de pe storer sa faca load balancing intre testerii disponibili si containerele de pe acestia.</p>

<p>> > Pe langa acestea, am implementat cate un executor pentru LXC si pentru KVM,<br>
> > iar acum refactorizez scripturile pentru a le face sa implementeze o<br>
> > interfata comuna.<br>
><br>
> GG!</p>