buildery: koncepcje i pewne pytania

[Tomasz Kłoczko]

On Sat, 1 Dec 2001, Witold Filipczyk wrote:
[..]
> > Po pierwsze trzeba określić jakie konkretnie dane trzeba zbierać i jaką 
> > metodą. Jeżeli to mają być wyniki z time to ponieważ jest tu kilka rzecy 
> > potencjalnie do usyskania to tzrebaby okreslić jak potrzbne dane mamy 
> > zbierać ? Mówiąc inaczje trzeba określić metodę pomiaru. Druga sprawa to 
> > metoda obróbki tych danych.
> > Mam tu niemniej osobiście tylko mgliste pojęcie o tym jakie dane zbierać i 
> > jak je obrabiać. Jęzli ktoś miałby tu jakieś konkretne pomysły jak to 
> > rozwiazać to prosze o zgłaszanie takich propozycji.
> 
> Zbierać maksymalnie dużo informacji, tyle na ile starczy miejsca.
> (Od przybytku głowa nie boli).
> Proponuję odpalić 'top' z odpowiednimi opcjami w szczególności opcją
> b i wyniki dopisywać do jakiegoś pliku.
> Z tych plików każdy będzie mógł sobie wyciągnąć to co będzie chciał.

Jeżeli już to nie z topa tylko z time dane należy wyciągać.
I znowu .. nie musimy się w tej chwili skupiać na obróbce danych. Jęzli 
juz to na obecnym etapie wystarczy tylko pzre,myśleć oc zbierac.

> > Założenia co do pracy builderów przebudowyaania pakietów w kółko są mnei 
> > wiecej takie:
[..]
> Wydaję mnie się, że sensownym rozwiązaniem byłoby gdyby wszystkie buildery
> miały wspólny system plików po NFSie read-only, a jeśli sieć jest za wolna
> to używane pliki zsynchronizowane z tym co w repo czy gdzieś tam.
> Odbiór wyników w jednym (kilku) katalogach (rw) lub przez jakąś bramkę. 

Nie ma takiej potrzeby. Przy założeniu że wszędzie sa używane takie same
zestawy pakietów byłoby to tylko nipotrzebne obciążanie NFS serwera, a i
kompilacja na maszynach klienckich byłaby mocno spowolniona.
Zamiast sie bawić w uwspólnianie zasobów lepiej zadbać żeby wszędzie było 
to samo. W ten sposób można znacznie lepiej wykorzystać lokalne zasoby 
dyskowe i moc procesora.
Tak czy inaczje z grubbsza transfer wyników i zleceń jest opracowany i tu 
juz nie ma co sobie zawracać głowy. W przypadku masowego budownia pakeitów 
odbiór będzie poczta . Wysyłanie zleceń pgp-niętym listem (kluczem 
serwera rodzielającego zlecenia).

Jeżeli znalazłoby się miejsce na ftp to możaby wystawić gdzieś nawet 
okresowo generowane spakowane archiwa z tym co jest na builderach o ile 
ktoś chciałby sobie tam pozaglądać i cos nawet z tym porobić. Niemniej 
zanim się to stanie tzreba będzie wydzielić transfer zasobów (i w zwiazku 
z tym takze klucze uzywane przy autentykacji) po za chroot po to zeby nie 
narażać kilku maszynek na głupie wejścia i żeby takze każdy mógł prosto 
osadzić pod wąłsną czapą do autentykacji zleceń i transferu wyników.

> Do tego kilka demonów po stronie builderów, każdy w oparciu o 'make', tzn.
> make odpalany w równych odstępach czasu.

Przyjrzyj się najpierw temu co jest obecnie w pld-builder bo zaczynasz 
"opracowywać" rzeczy które są juz zrobione :)
Sterowanie builderem jest zrealizowane pzrez procmaila i crona jako 
wyzwalacza budowania.

> Jeśli jakiś plik się pojawi w katalogu to go obrobić i wynik przerzucić do
> innego katalogu, w którym działa inny make z innym Makefile-m.
> W końcu w jednym katalogu wysyłka danych na komputerek zbiorczy.
> 
> 
> Przy okazji powtórzę jeszcze, że potrzebna jest też automatyka przy FTP,
> tzn. dla każdego nowego pakietu:
> 
> rpm -U pakiet --justdb

Rozumiem że to po to żeby możliwie wcześnie informować, że zasoby pakietu
wchdza w konflikt z czymś co już jest (?). Nie głupie ale jeżeli już to z
opcja --test (nie ma sensu wykonywac pełnegu upgrade a przy --justdb spora
ilość skryptów pre/post instalacycjnych nie ma wogołe szans sie wykonać).
Po za tym na builderach jest ściśle określony i wcale nie szetroki zestaw
pakiet (jest on zawężony do niezbędnego minimu w zasadzie) w ten sposób
przejdzie wiele bokiem. Choć przy odbiorze pakietu moze być to centralnie
wykonane względem gdzieś zeskładowanej bazy. Tak czy inaczej masz racje że
to może być jeden z pounków automatycznego testowania zasobu bezpośrenio 
po jego wygenerowaniu.

[..]
> Gdzie jest skrypt robiący .iso ?

W /.stat na ftp.pld.org.pl

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*