[vmchecker-dev] Reproiectarea comunicatiei storer-tester

[Lucian Adrian Grijincu]

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


Eu m-am apucat sa fac un alt front-end in django
(https://github.com/luciang/maat) care sa impinga taskuri in celery.
N-am apucat sa avansez prea mult pe treaba asta, dar codul e scurt si
clar in django.

O sa reinvii proiectul si o sa il fac sa trimita taskuri in celery
care sa faca ceva de genul "sleep 10; echo "works" > run-stdout.xxx"
si sa trimita fisierul "run-stdout.xxx" si ce-o mai fi nevoie ca
rezultat. O sa ramana dup-aia doar conversia taskurilor in ceva care
sa cheme commanderul de vmchecker, care n-ar trebui sa fie prea greu.

Alex: ai timp de un hangout zilele astea sa discutam de celery?
-- 
 .
..: Lucian