[vmchecker-dev] Reproiectarea comunicatiei storer-tester

[Vlad Dogaru]

2012/6/8 Valentin Gosu <valentin.gosu at gmail.com>:
>
> 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.

Sună bine, dar o parte din duplicare tot va exista;  fiecare thread de
pe tester va trebui să aibă propria imagine de mașină virtuală.  Nu
cred că există vreo soluție la asta, 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.

Yup, de aici și nevoia de SSH two-way (care se transforma în
three-way, hehe, get it? :D).

> 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.

A, adică să fie un singur queue-manager care să se joace cu inotify,
și ăsta să distribuie assignment-urile funcție de necesitățile lor și
de ce worker e liber?  Something like: dacă e temă la SO2, o pui pe
VMware sau KVM, dar nu LXC?  Sună ca lumea.

Mesajul inițial nu pomenea nimic de mai multe evaluări simultane, dar
trebuia să mă prind că e vorba de asta, altfel nu avea rost să existe
mai multe backend-uri de evaluare.

Vlad