[vmchecker-dev] Reproiectarea comunicatiei storer-tester

[Valentin Gosu]

On Jun 8, 2012 2:41 PM, "Vlad Dogaru" <ddvlad at rosedu.org> wrote:
>
> 2012/6/7 Valentin Gosu <valentin.gosu at gmail.com>:
> > Salut,
> >
> > In discutiile mele cu Razvan am determinat ca modul de comunicatie intre
> > storer si tester este defectuos, in principal modul cum este folosit
SSH-ul.
> >
> > In prezent, atat pe storer cat si pe tester trebuie sa existe conturi
pentru
> > fiecare materie, cu chei publice generate. La trimiterea unei teme de
catre
> > student (la SO de exemplu), aceasta se salveaza in repo, in home-ul
userului
> > SO, iar bundle-ul este trimis prin SSH catre contul SO de pe tester.
Acesta
> > este primit de queue-manager, ce ruleaza in contextul contului SO, iar
dupa
> > corectare se il copiaza inapoi prin SCP, in repo-ul de pe contul SO.
>
> E defectuos numai în situația în care maparea dintre userii de pe
> storer și tester nu e 1-to-1.
>
> Anul ăsta, pentru că avem o mașină nouă (care e o rachetă, îmi permit
> să adaug), fiecare curs are propriul user pe ambele mașini.
> Administratorii cursurilor în cauză pot (re)porni serviciul de
> testare, după cum pot edita și detalii despre assignments.  Nu văd
> ceva greșit în asta.

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.
>
> Ce era greșit era abordarea de anul trecut în care, forțați de
> împrejurări (no hardware), 2-3 cursuri împărțeau aceeași coadă și
> aveam probleme cu cheile SSH împrăștiate peste tot.  so at elf putea
> ajunge pe so at sanctuary, apoi pe so2 at elf.  Problema era "rezolvată" cu
> ACL-uri pe home-uri, which sucked, dar a fost rezolvată de-a binele
> prin alocarea unei mașini mai țepene, care poate rula mai mult de
> jumate de mașină virtuală simultan.
>
> > Pe langa faptul ca cheile publice pun probleme la adaugarea unei noi
> > materii, dorim sa reducem accesul statiei tester la fisierele de pe
storer.
> >
> > In acest sens, propunem urmatoarele modificari:
> > 1. Pe storer in contextul user-ului vmchecker sa ruleze un daemon care
se
> > ocupa de comunicatia cu tester-ul. Acesta trimite bundle-ul catre
storer si
> > este notificat cand se termina testarea, moment in care copiaza arhiva
> > local.
> > 2. Pe tester sa existe un singur user, in contextul caruia ruleaza
masinile
> > virtuale. Pe aceasta masina ruleaza un singur queue-manager care
detecteaza
> > existenta unui bundle nou (folosind inotify), testeaza, si notifica
daemonul
> > de pe storer. In acest fel, tester-ul nu are deloc acces pe storer.
>
> Asta nu e chiar atât de diferit față de ce avem acum.  Corectează-mă
> dacă greșesc, dar diferența este în faptul că nu se mai SCP-iază
> rezultatele pe storer, ci storerul e notificat și și le ia singur,
> right?
>
> E o problemă cu a rula o singură coadă: vmchecker.cs.pub.ro are 8
> core-uri, e o idee *bună* să avem o coadă per curs, ca să nu se
> reflecte un deadline la SO2 în RTT-ul temelor de la SD, de exemplu.
>

Din cate imi dau seama din callback.py, tester-ul trimite fisierele pe
storer.

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.

> > Pe langa acestea, am implementat cate un executor pentru LXC si pentru
KVM,
> > iar acum refactorizez scripturile pentru a le face sa implementeze o
> > interfata comuna.
>
> GG!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rosedu.org/pipermail/vmchecker-dev/attachments/20120608/e625cc9d/attachment.html>