[vmchecker-dev] Reproiectarea comunicatiei storer-tester

[Valentin Gosu]

2012/6/12 Alex Eftimie <alex at rosedu.org>:
> 2012/6/12 Razvan Deaconescu <razvan at rosedu.org>:
>>> 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?
>

Salut, eu pana acum am facut un daemon pentru storer, care va comunica
printr-o conexiune persistenta cu queue-manager.
Prin conexiune va fi notificat dupa terminarea testarii, si va copia
local rezultatele.

> Salut,
>
> Mă bag și eu în vorbă pentru că m-am jucat relativ recent cu celery,
> pentru a face un sistem distribuit de procesare de imagini/corectare
> de teste. Din experiența cu celery, acesta pare o soluție foarte bună
> pentru vmchecker, deoarece reprezintă manager-ul de mai sus - care
> știe de mai multe sisteme de testare (worker) și care să trimită
> job-urile către acestea.
>
> Celery face munca de abstractizare a worker nodes, peste un sistem de
> cozi de mesaje existent (precum rabbitmq, sau o bază de date). Poate
> monitoriza în starea nodurilor configurate, poate spune starea
> job-urilor, este flexibil și rapid.
>
> Din punct de vedere programatic, după setup (care poate fi făcut rapid
> cu defaults), trebuie doar scrise task-uri atomice, precum:
> "dezarhivează o arhivă", "rulează checker" etc. Restul, tot ce ține de
> rulare, captura rezultatului, distribuția pe noduri, este treaba
> celery.
>

Pare o idee buna, insa cred ca ar trebui modificata destul mult
stuctura curenta a vmchecker.
O sa arunc si eu o privire peste celery ca pare o unealta buna :D

Mersi
--
Valentin