skrypty builderów (Re: metodologia wypuszczania Ac)

[Michal Moskal]

On Sat, Jun 07, 2003 at 09:47:31PM +0200, Andrzej Krzysztofowicz wrote:
> > > To tylko jeden z przykladow. Dosc czesty.
> > 
> > To wiem. Chodziło mi o to, czy coś innego niż doinstalowanie BR
> > występuje w 10%, 1% czy 0.1% pakietów. Po prostu puszczając zlecenia na
> 
> Miedzy 1% a 10%, ZTCP.
> Chyba, ze liczysz BR pakiet, ktory czeka w kolejce do zbudowania...
> (kolejnosc wyslania zlecen != kolejnosc budowania)

Pomysł jest (teraz :-) taki:

1. grupy zleceń

Zlecenia można wysyłać po kilka sztuk na raz. Taka grupa zleceń jest
przetwarzana atomowo, w podanej kolejności. Jeśli budowanie jednego
pakietu z grupy się nie udało to przerywamy przetwarzanie grupy.

2. priorytety zleceń

Z kolejki wybieramy zlecenie o najwyższym priorytecie, które jest 
najstarsze. Priorytety przwiduję 3:

  * wysoki: sec-updajty. Powinno ich być mało (przynajmniej w trakcie
    masowego budowania dystrybucji), ponieważ psują kolejność budowania.

  * normalny: cała reszta.

  * niski: test/mass-buildy różne. Koniecznie z flags test-build (czyli
    wynikowych pakietów nie instalujemu na builderze)

> > Pozatym builder ma teraz opcję, że instaluje zbudowane pakiety. Tylko,
> > że to działa w 1/2 przypadków ze względu na zależności.
> 
> Nie jestem pewien, czy powinien. A jak to co sie wlasnie zbudowalo jest na
> tyle skopane, ze rozpieprzy system ?
> Wg koncepcji kloczka "zaakceptowaniem" pakietu dla instalacji na builderach
> mialo byc jago przejscie test -> ready.

Czekanie na przejście test -> ready jest IMHO nierealne, np. libtool ma
req-eq na gcc. I co przebudowujemy gcc i przerzucamy od razu do ready?
Przecież nie ma tam jeszcze libtoola. A w ready/ miały być pakiety spójne
pod względem zależności afaik.

> > Pytam dlatego, że doinstalowywanie i wywalanie BR może być rozwiązane
> > automatycznie (właśnie produkuje skrypty do tego). Jeśli zrobić tak jak
> > mówiłem (nie wywalać po budowaniu wszystkiego, ale tylko co co jest
> > zbędne dla następnego), to wydaje mi się, że można to zastosować na
> > builderach produkcyjnych. 
> 
> Tu tez mam watpliwosci.
> Nie do konca wierze, ze po
> 
> rpm -e pakiet;rpm -i pakiet
> 
> dostane *dokaldnie* taki sam stan systemu, jak przed wykonaniem tego.
> I nie chodzi mi tu a %files, a o pliki konfiguracyjne, skrypty %pre/%post
> i trigery. To czesto jest skopane.

AFAIK Pliki konfiguracyjne mają na builderach minimalne znaczenie, może
poza /etc/resolv.conf etc. W pakietach powinny być takie pliki konf,
żeby builder mógł na nich działać. Jakaś działająca domyślna konfiguracja.

A co do skryptów -- fakt, mogą się wywalić, mogą zrobić coś dziwnego
etc. Mogą zostać jakieś śmieci. Ale przecież dokładnie to samo się
dzieje w wypadku ręcznego instalowania pakietów.

> > No i jeśli budowanie będzie tylko kwestią puszczania zleceń (bez ssh
> > builder poldek -i ...), to powinno to pujść *znacznie* szybciej.
> 
> A roznice w szybkosci budowania pomiedzy architekturami ?
> A gdy zlecenie nie dojdzie na jakis builder na czas z powodu problemow z
> poczta ?

Ciężko wymusić, by zlecenia dochodziły w kolejności wysyłania,
szczególnie, jeśli wysyłających jest wielu. Ale IMHO kluczowa kwestia to
*taka sama* kolejność na wszystkich builderach. To na pewno rozjedzie
się przy zleceniach o wyższym priorytecie, ale to musimy przeboleć.

Natomiast dla pozostałych pomysł jest taki: zlecenia wysyłamy na
srcbuilder. Kolejność dochodzenia do niego jest obowiązująca. On buduje
srpm, wystawia je. 

Natomiast zlecenia dla innych builderów wystawia via http, wysyłając
tylko pocztą powiadomienie: ,,są nowe zlecenia''.

Po http wystwiony jest plik ze wszystkimi zleceniami z ostatnich
(powiedzmy) 30 dni.  Każde opatrzone numerem kolejnym, a buildery
pamiętają jaki był numer ostatnio przetwarzanego zlecenia.

Oczywiście z tym pliku opisane są również grupy zleceń.

> A gdy proces budowania jakiegos pakietu sie zapetli (zdarza sie!) na ktorejs
> architekturze ?

Trzeba killnąć, nie wiem jaki to ma związek z doinstalowywaniem BR.

> A gdy proces budowania wymaga niepodzielnych (per chroot) zasobow maszyny,
> jak np. pamiec wspolna, czy konkretny port TCP (problem przy wielu
> builderach w chroot)?

Magiczny komentarz w specu. Przynajmniej będzie wiadomo które to.

> > > Poza tym, jesli takimi decyzjami ma sie zajmowac CDG, to jest to czysta
> > > strata czasu.
> > 
> > IMHO CDG może zatwierdzić tylko ogólne założenia.
> 
> Wlasnie.
> A kto te zalozenia powinien wyartykulowac? Cezar? ;_)
> Nie widzialem jeszcze kandydatur na RM. A umiejetnosci tych osob sa
> baaaardzo wazne.

Ja mogę zrobić skrypty, na RM się nie nadaje.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith : GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::::: Wroclaw University, CS Dept : {E-,w}-- {b++,e}>+++ h