[vmchecker-dev] Reproiectarea comunicatiei storer-tester

[Razvan Deaconescu]

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.

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

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

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?

Răzvan