buildery: koncepcje i pewne pytania

[Tomasz Kłoczko]

(.. znowu będzie dłuzej ale chyba nie da się inaczej bo muszę zrzucić z 
czaszki pomysły które mi się lęgną w głowie od dłuzszego czasu :>)

Przedwczoraj w zasadzie zaczęło działać składowanie logów na buildlogs ale
nie pdoba mi się to za bardzo. Tutaj wspomnę tylko o tym co pisałem ze
dwa, trzy listy temu o zbieraniu informacji niejako przy okazji i potem
ich prezentacji jak argument. Otróż uświadomiłem sobie, że przy okazji
budowania pakietu meżemy wyciągnać niesamowicie ważne informacjie w
zasadzie za friko.

Ab owo (łać. "od jajka", bo rzymianie doszli do wniosku że najpierw było
jajko a potem kura .. Michał to nie o Tobie ;)

Mamy binarki optymalizowane pod różne architektóry. Mamy buildery. Od
kilku dni z kilkoma osobai próbuję mocniej przemyśleć sprawy związane z
budowaniem pakeitów, a takze z masowym przebudowywaniem pakietów w kółko
w celach testowych po tożeby mieć wieksze zaufanie do pakeitów 
pzrerzcacnych z /test do podstawowej hierarhii.
Co to w efekcie powinno nam dać:

- pewność że apkiety przerzucane w nowszej wersji/z jakimiś dodatkowymi 
  poprawkami nie mają wpły na to czy resztą sie przestaje budować,

- 100% danych na temat tego co dokładmnie trzeba będzie poprawić w związku 
  z wprowadzeniem wprowadzniem pakeitu który moze bruździć przy ufowaniu 
  pakietów i/lub które pakeity znowu sie buduja o ile jakiś pakeit 
  potrzebny im do budowania dostał poprawkę która była włąsciwą przyczyna 
  pojawiania się błedów w trakcie budowania innych pakietów.

W tej chwili mamy conajmenie dwie grupy pakietów które są narażone na tego
typu objawy niejako samoistnie. Są to pakiety KDE i GNOME e których ilość
i zakres różncyh zmian z wersji na wersje daje czasami efekty nie do
przewidznia zanim jakiś pakiet nie wprowadzi się w nowej wersji do
eksploatacji. Powyśze bęzie miało np. fundamentalne znacznie przy
przejściu na nowe db czy też w kolejce dalej o ile w pewnym momencie 
pzrejdziemy na gcc 3.x. I miałaby kolosalne znacznie w momencie kiedy 
wprowadzaliśmy autoconfa, automake w celu oszacowania tego jaki zakres 
zmian w reszcie zasobów bezie to wymagać jesli chdzi o potrzebne poprawki.
Dalej: w trakcie już poprawiania błędów wynikajacych z wprowadznia 
jakiegoś pakietu na bieżąco dałoby to nam stały wgląd w skutki poprawek 
(załóżmy że został znaleziony błąd w automake i po jego poprawieniu i 
próbnym wejsciu do eksploatacji poprawionego automake momentalnie dzieki 
temu bęziemy mieli informacje o skutkach tych zmian).

Dobra .. są plany wprowadznia budowania pakietów coś na zasadzie 
distrybuted computing z pewnymi modyfikacjami. Ale jako to ma związek 
z wyciąganiem przy tej okacji jakiś istotnych informacji ?

Otóże zwiazek jest i to całkiem prosty. Otóż budowanie zasobów jakie mamy
jest dość dobrym testem wydajności systemu. Jeżeli bendą np. trzy
dokładnie takei same mazynki ale z zainstalowanymi pakietami
zoptymalizowanymi pod różne arhitektóry to wyciągjąc informacje o tym
jakie było obciązenie i czas kompilacji poszczególnych pakietów mozna
będzie określić (wreszcie)  zupełnie namacalnie jaki ma to sens co robimy
z budowniem pakietów pod trzy rózne arch x86. Co wiecej jeżeli óżnice bedą
to bedzie mozńą uzyskać konkretne dane dotyczące tych róznic które beą
potencjalnie dosć bliskie róznuicom jakie moga się pojawić przy innych
zastosowaniach np. web hosting z dużą ilością aktywnych aktywnych stron.
Mówiąc inaczje dzięki tym danym można będzie się posługiwać racjonalnymi
argumentami dlaczego należy bąć nie instalować binarki zoptymalizowane pod
konkretną arch.

Co dalej jeżeli maszynki bedą takie same, a rózne benda np. systemy
plikowe to z racji tego że kompilacja to tez coś co dość mocno obciąża
operacje plikowe to też będzie można uzyskać tu dane niejako przy okazji
które pozwiolą wybrać taki a nie inny system plikowy na podstawie
racjonalnych danych.

Dalej jeszcze. Załóżmy że zmieniamy kompilator. Dziki przechowywaniu 
danych z poprzednich kompilacji możemy próbować określić czy zmiana 
kompilatora ma jakiś widoczny wpływ na wydajnośc system. Zapewne 
informacji które bedzie można tu wyciągnąć bezie jeszcze kilka ale ..

Mówiąc inaczje teraz jest najlepsza pora żeby minimalnym nakłądem parcy 
uzyskać maksymalny efekt w postaci dodatkowych dostosowań w pld-builder po 
to żeby tanim pkossztem pozyskać cenne dane.

Co jest potrzebne do tego żeby powyższe zrealizować ?

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.

Założenia co do pracy builderów przebudowyaania pakietów w kółko są mnei 
wiecej takie:
- jest maszynka zajmujaca się rozdzielaniem pakietów miezy resztę maszynek 
  i na której są zbierane i obrabiane wyniki takich budowań,
- każdy będzie mógł zgłosić swoja maszynke do pzrebudowywanai pakietów,
- builder przy okazji budowania bezie mógł zwrócić dodatkowe dane 
  dotyczące obciązenai i czasu kompilacji pakietu,
- dane o builderach zgłasznych są niejawne i upublicznieniu podlegać bendą 
  tylko dane sumaryczne z budowań (ilość jednostek, ilość jednostek 
  konkretnego typu, czas pzrebudowanai całosci i inne dane które da sie z 
  tego wyciagnąć). Jeżeli ktoś by chciał żeby dane dotycżace tego że 
  urzyczył jakąś jednostkę na budowanie były publicznie dosepne ("kto nas 
  wspiera ?") to nie widże żeby też to prezentować.
- zapewnić trzeba powtarzalnosć środowisk budownych pakietów.

Ostani punk nieco rozwinę. Otóż wiadomo że całość bezie się operać o 
chrootowe środowisko jakei mamy w pakiecie pld-builder. Przed zbudownaiem 
pakirtu musi nastapić swego rodzju weryfikacja tego czy na builderze jest 
zainstalwoamny właściwy/konkretny zestaw pakietów i to mzan zrobić bardzo 
prosto wystarczy choćby wygeneroewac sumę md5 z rpm -qa w chroot. Jeżeli 
suma bezie właściwa to jednostka dostaje pakiet do pzrebudowani, a jeżlei 
nie to tutaj powinna nasapić dodatkowa iteracja związana z 
usupełnieniem/korektą tego co jest potrzebne w środowisku do budowanai 
pakietów. Można się tu zastanowić jak powinna wyglądać taka wymiana danych 
żeby mozliwie to zautomatyzować i żeby zapewnić możliwie wysoki poziom 
powtarzalności takich środowisk.
Po metotodzie zbieranai danych o obciżeniu jest to koleny punk który bezie 
wymagał pzremyslenia do końca.

Po przebudowaniu pakietu jednostka która go zbudowała zwraca tylko dane 
sumaryczne: czy pakiet sie przebidował i o ile ktoś chciałby pomóc w 
kompletownaiu danych dotyczacych wydajności inne dane dotyczace 
obciążenia.

Tak czy inacje ze względu na zbiranie logów w tej chwili i tak środowisko 
sterujace budowniem pakietów (pld-builder)wymaga przeróbek. Tutaj Arek
zgłąszał że mu sie niepodoba dwuwarstwowoć buildera. Wydaje się że jest to 
nie do unikniecia ale są pewne szczegóły które należy poprawić zmianić juz 
nie tylko z powodów czysto estetycznych:
* W  tej chwili zwracanie wyników z obecnego pld-buidera służszącego 
  przedewszystkim do robienia zasobów produkcyjnych połączone jest z tym, 
  że zwracanie pakeitów wynikowych i logów odbywa s ie z chroot. Jest to 
  błędogenna konstrukcja ponieważ automatyka drugiej warstwy w chroot 
  powinna zajmować się wyłacnie pzrebudowaniem pakeitów i wyprodukowaniem 
  wynikowych danych z budowania.
  Nie ejstem w stanie dokąłdnie tego uzasadnić ale takie rozdzielenie 
  rozdzielenie powinno być IMHO puilnowane ze względów bezpieczeństwa.

* Całe sterowanie i transwer danych wynikowych powinno odbywać się z 
  warstwy wyższej z nad chroot. Jest conajmniej kilka argumentów na to że 
  tak właśnie się powinno to odbywać. Pirwszy jest taki że jeżeli budownie 
  i transfer dancyh odbywa się jednotorowo to przy zakłóceniach na łączach 
  w trakcie zwracanai pakietów/danych wynikowych tracony jest czas który 
  mógłby być wykorzystany na rozpocżecie budowania kolenjego pakietu.
  W tej chwili w tym co mamy dzieki temu co Janek kiedyś zrobił mamy juz 
  wyraźne rozdzielenie między odbieraniem zleceń i ich pzretwarzaniem. To 
  jest niewątpliwie dobry model ale wymagać bezie uzupełnienia o tzrecią 
  linię czynnosć wykonywanych równolegle - o zwracanie dancyh wynikowych.
  Zrozwiazać mzan bezie to prosto popzrez dodanie ~builder/spool w chroot 
  i dodatkowym skryptom uruchamianym z crona którebędą sprawdzać cy jest 
  coś tam i zajmą się pzretransportowaniem tego we włąsciwe miejsce i 
  właściwą metodą (smtp/scp/ftp ov. SSL). tak czy inaczej automatyka do 
  tego musi operować z poza chroot po to zeby to co jest wykonywane w 
  chroot zajmowało się czystym budowniem pakietów i niczym więcej.
  Jezeli pakiet nie pzrebufoewał się prawidłowo to w ~builder/spool takze 
  powonna o tym trafić informacja po to żeby na warstwie sterujacej 
  wysyłaniem wymników moząń było choćby w tytule listu przekazać że 
  budownie sie nie udało a build log leży pod adresm <jakimśtam>.

* Pakiety moga być budowane z konkretnymi włączonymi bąć nie dodatkowymi 
  cechami sterowanymi przez --{with,without} czy --define <ficzer> <val>
  Jeżlei mają być zbierane logi takze z takich budowań to musi być jeszcze 
  usystematyzowany sposób w jaki beą składowane ogi z takich buowań.
  Propozycja jest tu taka żeby w zlecenaich odseparować nazę speca od 
  dodatkowch parametrów. Mówiąc inaczej opócz pól X-Spec: w zleceniu 
  przesyłanym poczta doszłyby dodatkowo X-CVS-Tag: i X-Defines:.
  To co z tych pól bezie wyciągane będzie można użyć przy konstruowaniu 
  nazwy pliku loga czy też też w komunikatach zwrotnych co  i z jakimi 
  parametrami udało się zbudować czy też nie.
  W tym miejscu nie mam jeszcze pomysłu na kowencje według jakiej ba 
  buildlogs logi z tego typu budowań byłyby pzrechowywane.
  Czyli mówiąc inaczje jest to kolejne pytanie na jakie ztreba sobie 
  możliwie szybko odpwoeidzieć. jeżlei ktoś miałbyu pomysły w tej kwestii 
  to też bym prosił.

Podsumowując. W tej chwili budowanie pakeiytóe na builderach jest 
wstrzymane. jezli powidzmy do jutra nie uda się tego rozwiącać na poziomie 
umozliwiającym przetrwarzanei zleceń na beirzaco to zostanie tak jak jest 
obecnie po to żeby dac sobie czas na skompletowanie reszty automatyki w 
pld-builder wypałniajacej powyższe załozenia. W dalszej kolejnosci 
pld-builder powinien być dostosowywany do tego żeby po odpowiednim 
skonfigurowaniu można było go wykorzystać do budowania pakietów w kółko 
na tak dużej ilości maszynek jak to nam sie tylko uda. Ilość maszynek 
powinna być na yle duża żeby pzredudowanie całości było mozliwe powiedźmy 
w jeden dzień i żeby takze czyk pzrerzucanai pakietów z /test miał w 
zwiażku z tym nei za długi czas.

Nie oczekuję za mocnio że ktoś zacznie pomagać mi w modyfikowaniu 
pld-buildera ale byłbym bardzo wdzięczny za analizę powyższego i 
zglaszanie wszelkich już choćby wątpliwości, a na pewno jeszcze lepiej 
propozycji rozwiazania tego co jeszcze w powyszych koncepcjach jeszcze 
brakuje/jest niespójne.

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*