ra-general-updates: kto, z kim, kiedy ?

[Tomasz Kłoczko]

On Tue, 10 Dec 2002, Marcin Bohosiewicz wrote:
[..
> Dla ix86 (i386,i586,i686) i ppc buildery sa i sie kurza.
> Alpha chyba w CS tez juz stoi gotowa do uzytku.

Tak czy inaczje jest to tylko kopia builderów Ra.
Długo byłem cierpliwy obsługijać to dość ręcznie. Wątpie zbey ktokolwiek 
wytrzymał to dłużej. Ja już mam z lekka dość .. i to tym bardziej że 
czeka nas conajmniej dwu, trzy ktotne przebudowanie całość zanim zacznie 
zamykanie 2.0. Już samo to jest wstaczającym powodem żeby nie robić za 
dużo w obarciu o obecne schematy nie śpiesżać sie z możliwie szerokim 
rozbudowaniem funkcjonalnosci builderów i narzędzi które beda operować na 
pakeitach po stronie ftp serwera wspomagając przenoszenie pakeitów w 
takich zbiorach żeby nikt nie musiał narzekać juz na to że cżęść rzeczy 
rozjechała się w zależnościach.
Teraz jest właściwy czas na to żeby to przemyśleć bo potem jak cały młyn 
się zacznie już kręcić z pełna prędkoscią zmiany tego typu będą wczhodzić
dość opornie.

IMHO do tego żeby dopracować tą ayutomatykę jest potrzebne szersze 
uzywanie builderów po za bezpośrednia produkcja zasobów dystrybucyjnych. 
Dobrym bodźcem do czegos takiego może być rozbudowanie funcjonalności 
builderów o to żeby mogły służyć do przebudowywanai pakietów na zasadach 
distributed computing czyli żeby kazdy majac zosrganizowane u siebie 
środowisko do przebudowywania pakietów mógł zgłosić włąsna maszynkę co 
spowoduje że bedzie mógł dostawać zlecenai pzrebudowywanai pakietów w 
środowisku pakietów takich samych jak na produkcyjnych builderch.

Wszystko to po to żeby po wprowadzeniue nawet niewielkich zmian w takowym 
środowuisku móc wychwytywać konsekwencje takich zmian, gromadząc tego typu 
informacje po to żeby było niemal w każdej chwili co w danym momencie się 
nie buduje.

Rozdzielacz takich zleceń to rzecz dosć prosta. Dużo bardziej 
skomplikowane będzie dorobienie do tego tego co bezie obrabiać wyniki 
zleceń.

Tak czy inczje IMHO do obecnech buildera wartoby dorobić nasepujące 
funcje:
- cancel zlecenia które czy to jest jesszcze w klejce czy to wąłsnie jest 
  w trakcie realizacji,
- zlecenie z priorytetem - np. po to żeby nawet ptrodukcyjne buuldery 
  wykorzystywax cdo tego zeby mogłgły uczestniczyć w testowym w kółko 
  wykonywanym budowaniu pakietów .. tego typu zlecenia powinny iść z 
  niskim priorytetem ale zlecenie "produkcyjne" powinno wejść jako 
  pierwsze po najbliższym skończeniu budowania pakietu,
- mozliwość pzrekazywania w zleceniu czy jest to test build czy zlecenie
  produkcyjne - zlecenia drugie typu beda kończyć się oddaniem w określone 
  mijsce build logów (bez względu na to czy budowanie sie powodło czy 
  nie) i pakeitów wynikowych,
- builder powinien zawsze budować tylko binarne pakiety lub tylko 
  źródłowe,
- z powyższym związane jest wysyłanie po pomyślnym produkcyjnym buildzie 
  sygnału o tym że można wygenerowac pakeit źródłowy. Tutaj w sumie 
  buildery binarek mogłby od razu generować same zlecenia wygenerowania na 
  builder źródłowy. Kwestia tylk ozastanowienai się jak obsługiwać 
  budowanie źródłowych pakietów w sytuacji keidy wiadomo ze takei zlecenia 
  nie podeślą wszystkie buildery, a także to że część pakeitów jest arch 
  specyfic,
- mniejważne le takze moznaby przewidzieć obsługę zlecenia w którym 
  oddawane bezie to co w danym momencie się buduje i co jest jeszcze 
  kolejce (choćby do monitorowania tego co się dzieje i stwierdzani które 
  buildery z tych które uczęstniczą w massiv building są w danym moencie 
  aktrywne co mzoę być także pomocne w ponownym wysłaniu zlecenia 
  przebudowania jakiegoś pakietu na inny builder,
- część maszynek uczestnicżacych w budowaniu bedzie w stanei odbuierać 
  zlecenia budowanai pakeitół na kilak architektór tak jak to jest z x86 
  czy będzie za kawałek z sparc. Wobec tego pzrysdałoby się mieć mozliwość 
  wspólnego gospodarowania ilościa różnolegle obrabianych zleceń i to 
  zwrówno po to żeby majac np. konto buildera przyjmujące zmlecenia które 
  obsługuje kilak architektór ale ma obsługiwać tylko np. jedno budowanie 
  w danym momencie jak i po to żbey majac builder tylko na jedna arch ale 
  mając np. maszynke SMP godzić sie na to że będzie sie w ramach jednego 
  środowiska budować kilak pakietów róznolegle,
- o ile będziemy rozbudowywać automatyczne testowanie pakietów to 
  conajmniej kilka rzeczy mzoę wymagać żeby owe testy były pzreprowadzane 
  w sytuacji keidy nic innego nie bedzie próbować dotykać jakich zasobów
  czyli że z czasem może się rozwinąć dodatrkowyindeks pakitów które 
  takiej wyłacznosic przy budowaniu beda potrzebowały (będzie to wazne w 
  śrosdowiskach buildewrów które beda dopuszczać budowanie równolegle na 
  kilku arch).

Komuś przychodzi jeszcze coś do głowy ?
A jeszcze jedno. W przypadku builderów z obsługą kilku arch odbieranie
zleceń powinno być mosliwei niezależne od MTA. IMHO to co wpada do 
chrootów jeśli chodzi o to co jest tam zamontowane an koncie builder nie 
powinno yć wprost instalwane z rpma0- tylko generowane. to znaczy się że 
po zainstalowaniu pakeityu pld-builder, po zdecydowaniu ile zleceń bezie 
się chciało obsługiwać (równolegle) z template katalogu i listy pakeitów 
obecnego build środowiska (dosepne na głownych ftp) powinno naswpić 
wygenerownie chrootów, zainstalwoanei w nich potrzebncyh pakietów i 
odpowidnich sktyptów w template katalogu. Takze z crona powinno być 
obsługiwane (np. raz na dzień) aktuwalizowanie zawartości builderów ale 
także mogłoby isstnieć zlecenie wykonujące takową aaktualziacje po to zeby 
niezwłocznie móc zainstalowac jakieś pakiet w build środowiskach.
Na czas takiej operacji oczywiście w danych chroot nie powinno być 
wykonywane ządne budowanie. W sumie z croan mogłby być wrzucene loklnie 
takie zlecenie raz na dzień (już bez autentykacji).

Z powyzszym wiąże się składowanie logów z aktualizacji pakietów (do
wynboru zdalnie lub tylko lokalnie). Powinno meić to duze znacznie w 
diagnostyce jakis zakłuceń generowanych przez nowo pojaiwajace się 
pakiety.

Pwyższe to dość szetrki plan ale wejść na ścieżke jego realizacji wejsć i 
tak trzeab bo bez tego urobimy sie po łokcie a efektu z tego wielkiego nie 
bedzie .. zabawy także.

Jeżeli komuś jeszcze nasuwają sie tu jakieś przemyślenia co do powyższego 
to proszę ..

Do powyższro jeszcze tzreba bedzie domontować automatyke działakjcą po 
stonie repozytorium gotowych pakeitó czyli transwer pakietów do punktu 
pośredniego, automatyczne podpisywanie pakietów w tym punkcie i 
automatyczne przenoszenie grup pakietów z takiego pośrednaika do 
podstwowego dzrewka w taki sposób żeby nie zryuwać zależnosci w 
głównym drzewku (tu będzie potrzebna przy tym na pewno pomoc Pawła :).


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*