[vmchecker-dev] Reproiectarea comunicatiei storer-tester

[Lucian Adrian Grijincu]

2012/6/12 Razvan Deaconescu <razvan at rosedu.org>:
> Lucian Adrian Grijincu <lucian.grijincu at gmail.com> writes:
>> 2012/6/8 Vlad Dogaru <ddvlad at rosedu.org>:
>>> A, adică să fie un singur queue-manager care să se joace cu inotify,
>>
>> Propunerea mea e sa trecem de la sistemul curent:
>>  1. scp files from storer to tester
>>  2. inotify notifies queue-manager
>>  3. queue-manager starts and waits for the task to complete
>>  4. scp results from tester to storer
>
> Unde rulează queue-manager-ul? Pe tester? Cred că este exact ceea ce am
> propus și noi.


Da, pe tester. Dar noi nu mai scriem queue managerul. Folosim unul
deja facut care are niste feature-uri interesante.



> Noi vrem să facem 4 prin inițierea conexiunii tot de la storer. Ca să
> evităm dubla configurare de chei SSH (cu dezavantajul că nu mai
> controlăm cine are acces unde).

Nu mai tin minte cum merge in celery chestia asta, dar parca pe storer
rula un demon de celery care comunica cu demonul de pe tester. Demonul
de pe storer stia de taskurile pornite din vmchecker si stia sa se
uite dupa rezultatul lor, sau daca nu poate ca demonul de pe tester
stia sa le pompeze catre cel de pe storer. Oricum, nu te intereseaza,
comunicatia e facuta intern.


> Vali propunea un serviciu pe tester care să fie interogat de storer și
> care să-i spună dacă s-a terminat un job.

Celery are asa ceva.

> Practic ar exista un queue-manager pe tester pentru a comanda testarea
> (pașii 2 și 3 descriși de tine) și un "remote notification service" care
> îi spune storer-ului (fie la interogarea storer-ului, fie pe conexiunea
> persistentă între storer și tester) că s-a terminat treaba. Apoi
> storer-ul ar efectua pasul 4. Încă nu am decis dacă să fie două procese
> dedicate (caz în care e nevoie de un IPC) sau de un proces cu două
> roluri: queue manager și remote notification service.
>
>> La un sistem in care folosim un task-queue distribuit si debugat deja:
>>  1. start a new async task from storer
>>  2. task-queue does magic and runs the task
>>  3. task dumps results to db
>>
>> Are vre-unul din voi experienta cu task-queue-uri distribuite?
>
> Adică? Să ruleze un "manager" care să știe de mai multe sisteme de
> testare cărora să la trimită job-ul?


Intrebam daca a mai folosit cineva celery sau un echivalent, ca sa ne
lamureasca daca exista probleme cu designul pe care il propuneam.


Din cate imi dau seama discutam cam de aceleasi lucruri, dar voi aveti
solutie in-house, eu zic sa folosim ceva facut de altii pentru a
rezolva problema asta.


-- 
 .
..: Lucian