Zróbmy w końcu pld-builder!

[Witold Filipczyk]

Diagram przepływu danych w pld-builder:
                                              NIE                        
                                             +----> KOSZ
  zlecenie budowy SRPM (a)     Weryfikacja(b)|                                
--------------------------> JZ --------------+
                                             |TAK
                                             +----> BUILDER SRPMS(c)
                                                         
                                                    NIE
                                                  +-----> KOSZ
               Budowa SRPMS       Weryfikacja2(d) |
BUILDER SRPMS --------------> JZ -----------------+
                                                  | TAK
                                                  +-----> DO KOLEJKI(e)

JZ - jednostka zarządzająca


*************************************************************************

            "daj mi coś do roboty"           "i mnie"
KLIENT1(f)------------------------> ZK (g) <-------- KLIENT2(g)
 |                                   |                     |
 |         "masz"                    |                     |
 + - - - - - - - - - - - - - - - - - +                     |
                                     |     "masz"          |
                                     + - - - - - - - - - - +

ZK - zarządca kolejki


Po zbudowaniu:
            Przesyła wyniki
KLIENT1 ---------------------------> ZKB (h)

                             FAIL
                            +------ logi do BUIDLOGS/FAIL 
      zapisuje rezulaty     |
ZKB ------------------------+
                            |OK
                            +------ logi do BUILDLOGS/OK, RPMS do podpisu

ZKB - zarządca kolejki BUDOWANE.

**************************************************************************

         podpisuje RPMS
SIGNER --------------------> TEST 


         kwarantanna
TEST   --------------------> DO_PRZERZUTU

                                                   NIE
                                                 +------> Czekaj
              "czy można zrobić upgrade na FTP?  |
DO_PRZERZUTU ------------------------------------+
                                                 | TAK
                                                 +------> Upgrade

**************************************************************************


Krótki opis:
Ktoś zleca zbudowanie pakietu.  Zlecenie jest weryfikowane przez
jednostkę zarządzającą (JZ).  Według mnie weryfikację można pominąć, ale na razie
niech zostanie.

BUILDER SRPMS ściąga źródła, buduje pakiet źródłowy.  Pakiet źródłowy ponownie
zostaje zweryfikowany.  Po zaakceptowaniu pakiet zostanie dopisany do kolejek
dla różnych builderów.

ZK jest serwerem iteracyjnym, przyjmuje zgłoszenia od klientów.
Po odebraniu zgłoszenia i weryfikacji klienta przesuwa element z czoła kolejki
do folderu BUDOWANE, "daję robotę klientowi" i czeka na następne zgłoszenie.
Dla każdej architektury jest oddzielny ZK.


KLIENT autentykuje się u ZK, dostaje pakiet do zbudowania, buduje go.
Wyniki wysyła do ZKB, autentykując się wcześniej.
Zgłasza się do ZK po następny pakiet do zbudowania.
Jeśli nie ma nic do budowania zasypia na określony czas i powtarza próbę.

ZKB zarządza folderem BUDOWANE.  Jest serwerem współbieżnym.
Autentykuje klientów, przyjmuje wyniki.  Zapisuje buildlogi w BUILDLOGS/,
RPMS w test/, usuwa elementy z folderu BUDOWANE.

Dla każdego zlecenia budowy określany jest timeout.  Jeśli w tym czasie
nie zostaną przysłane wyniki.  Klient otrzymuje dużego minusa, a pakiet
jest cofany do kolejki.

Przed trafieniem do test możliwa jest jeszcze WERYFIKACJA.

SIGNER podpisuje.  Tu nie ma problemu.

Po odbyciu kwarantanny w test jeśli pakiet nadaje się do użytku
zostanie skopiowany do folderu DO_PRZERZUTU.
Tam oczekuje na "desant".  Jeśli wszystko jest w porządku, wszystkie
zależności na FTP będą spełnione pakietu zostaną przerzucone na FTP.

Poza serwowaniem plików nie ma zbyt dużo roboty po stronie
serwera, a czas poświęcony na serwowanie tych plików stanowi ułamek
czasu poświęconego na serwowanie plików przez FTP, więc proponuję,
żeby serwer był na tej samej maszynie co FTP.
Zdecydowanie ułatwi to admistrowanie zasobami.

*************************************************************************

Na powyższym diagramie zostało to podzielone na trzy części.
Proponuję poświęcić po dwa dni na każdą część: średnio jeden dzień na omówienie,
jeden na implementację.
Proponuję zacząć od środka, ponieważ wydaje mi się to najłatwiejsze.

Jeśli idzie o sposób autentykacji, proponuję:
HTTP AUTH po https.

ZK po zleceniu, które zawsze wygląda tak samo:
"give me something"
przekierowuje na URL z pakietem SRPM.

Klient ściąga pakiet do zbudowania.
Buduje go.
Odsyła wyniki.

W przypadku budowania pronuję budować zawsze w takich samych warunkach,
tzn. pakiety zaciągane od zera z tego samego źródła, budowanie w chroocie.
Skrypt poldekbuild potrafi dociągnąć potrzebne pakiety.  Nie powinno być
problemu.

-- 
Witold Filipczyk
<witekfl w poczta.onet.pl>