Arete Slave TODO Questions

[rpt]

1. Jak robię sanity check i coś pójdzie nie tak to od razu wysyłam do Master'a 401 Check Failed. Mam zapisane output'y i returncode'y dla check'a który się wysypał i wcześniejszych. Czy pozostałe checki mają się wykonać i czy zasygnalizować jakoś Master'owi który check się wysypał, czy sam sobie pobierze i to sprawdzi. Swoją drogą jeszcze nic w tym kierunku w Masterze nie jest zrobione.
2. Komendy Setup - co ma się dziać jeśli któraś z nich się nie powiedzie i co jeśli nie zdążą się wykonać przed datetime'em rozpoczęcia testu? Są uruchamiane zaraz po komendzie start, żeby miały jak najwięcej czasu.
3. Chcę dorobić pobieranie konkretnych parametrów, np. po to, żeby dało się pobrać i output i returncode z komend check. Jakieś propozycje składni?

[qsorix]

ad. 1. Nie ma sensu wykonywac pozostalych checkow. Wyniki master powinien odebrac ze wszystkich, ktore sie wykonaly (lacznie z tym, ktory failowal). Moze Slave powinien prezentowac liste ID komend, dla ktorych ma dostepne wyniki? Tak samo -- w oparciu o te liste, moznaby wyniki pobierac po tescie. To pozostawiam Tobie, zaimplementuj tak, jak jest prosciej ;-)

ad 2. Jesli ktoras sie nie powiedzie test powinien zostac przerwany. Musza zostac uruchomione wszystkie komendy cleanup. Mozemy failowac test, jesli setup sie nie skonczyl. Zwracac w tym wypadku odpowiedni, kod bledu, zeby Master rozpoznal problem. W konfiguracji mozna podac delay na faze setup, wiec user jak zobaczy taki blad, powinien sobie ten delay zwiekszyc.

ad 3. Jeszcze timestamp. Propozycje skladni... teraz to jest afair get @{id=id} czy cos takiego? mozna zrobic get @{id=id.output}, get @{id=id.returncode}... no nie wiem. Cos ci chodzi po glowie to tak zrob.

[rpt]

ad 3. Takie coś wykminiłem:

get @{id.param} - odbiera parametry komendy get @{param} - odbiera parametry testu i daemon'a

id.params:

• output, returncode - parametry komend,
• started_at, duration - dodatkowe parametry komend 'task'

params:

• checks, setups, tasks, cleans - listy komend które posiadają output
• tmpdir, dbname - parametry z konfiguracji daemon'a
• started_at, duration - parametry testu

Jakieś protesty? Czegoś brakuje?

[qsorix]

IMHO nie ma potrzeby rozróżniać w tym pobieraniu wyników czy komenda była w check, setup, task czy cleanup. Chyba, że tak jest łatwiej. Za to po stronie frontendu będzie trudniej.

started_at -- rozumiem. duration -- czas trwania czy run_policy? jak czas trwania to ok, jak run_policy to nie ma potrzeby -- master to wie.

params tmpdir i dbname nie sa po stronie mastera potrzebne. started_at moze byc. duration master wie, chyba, ze tam bedzie rzeczywisty czas, a nie ten zadany.

checks, setups, tasks, cleans -- to rozumiem glownie w celu pobrania listy wykonanych checks?

[rpt]

Zrobione wszystko o czym tutaj była mowa. Zamykam.