search

qsorix / rpt-qrx-msc

1 stars 0 forks source link

daemon protocol - uwagi do protokołu #3

Closed qsorix closed 14 years ago

qsorix commented 14 years ago 
test @{name=<name>} @{duration=<seconds>}

Do duration to właściwie ostatnia rzecz, której nie wiem jak zrobić w tej mojej całej konfiguracji. Ale prawdopodobnie to nie będzie takie proste jak tutaj.

Myślę nad wprowadzeniem osobnej linijki określajacej sposób zakończenia testu. Chodzą mi po głowie na razie trzy:

Nie wiem czy to wystarczy i jak to zrobić. Nie mam pomysłu na prostą globalną synchronizację, która jest potrzebna do pomiaru czasu dystrybucji torrenta. Tzn. tam trzeba na każdym hoście zaczekać, aż ostatni skończy ściągać. Czyli na dobrą sprawę jak host kończy ściągać to musi wykonać jakąś komendę, która poinformuje kontroler, że już koniec.

    file @{name=<name>} @{size=<size>} @{output=<path>}

output to sobie deamon sam określa. kontroler nie będzie mówił, gdzie plik zapisać.

    check @{name=<name>} <command>

Uznałem u siebie w kodzie, że 'id' jest lepsze od 'name' bo od razu wiadomo, że ma być unikalne i tak dla wszystkich komend zrobiłem. ;)

    schedule @{name=<name>} @{at=<second>|every=<seconds>} @{output=<path>}? <command>

Nie wiem czy ten output będzie potrzebny. Na pewno nie chcę z kontrolera wysyłać ścieżek. Wolałbym jakoś tak np. @{output=redirect-to-file} i jak inna komenda chce się do niego odwołać to sobie robi @{.output.path}. Na razie nie wspieram takich zaawansowanych rzeczy. Trzeba spisać pomysły i coś spójnego zaplanować.

2.2 Sprawdzenie poprawności testu i jego uruchomienie

check @{name=<name>}
start @{name=<name> @{at=<datetime>|in=<seconds>}
stop @{name=<name>}

Ten stop to patrz wyżej o duration. Może się przydać, na razie nie używałem. BTW: może zrób check start, check stop. test start, test stop. Albo start check, stop check i start test, stop check. Teraz mi przyszło do głowy, że jak check miałby długo trwać, a na jakimś hoście poleci błąd, to można od razu przerwać check na pozostałych i nie czekać.

2.3 Odbieranie wyników

results @{name=<name>}
file @{name=<name>}
schedule @{name=<name>}
end

Możesz opisać dokładniej jak to ma wygladać? Co robi schedule?

rpt commented 14 years ago
  1. duration (oraz inne jego odmiany) proponuję dać przy 'start test', a nie przy samej konfiguracji testu. A poza tym to proponuję pisać 'duration=10' - trwa ileśtam | 'until=warunek' - tego jeszcze nie bardzo widzę jak by to można było zrobić, ale pogadamy | jak nie ma nic to test się kończy jak się skończy ostatni task.
  2. 'task' zamiast 'schedule' podoba mi się znacznie.
  3. 'output' przy 'file' i 'task' myślałem po to, żeby dało się wgrać/wygenerować jakieś pliki konfiguracyjne dla innych programów. Wydaje mi się, że to może się przydać - pomyśl.
  4. Same 'check' i 'start' oraz jeden 'stop' wydają mi się dobre, bo jednocześnie nie będzie się wykonywał chyba check i sam test, więc 'stop' będzie wiedział co zatrzymać (wszystko jest z jednym argumentem - id testu - uruchamiane)
  5. schedule (które chcę, żeby było 'task'iem) będzie przesyłać output komendy którą wcześniej wrzuciłeś do testu z jakimś tam id. A jak dokładnie będzie wyglądać całe wysyłanie wyników to się dogadamy jak będzie zrobione.
  6. Zanim wrócisz poprawię jeszcze ten cały protokół i wtedy pogadamy o jakichś jeszcze zmianach ewentualnych.
qsorix commented 14 years ago
  1. OK. Ten until warunek to można zrobić tak, jak mówiłem na jabbie. Tzn. ten motyw z wysyłaniem do demona sygnału. Tylko to w ogólnej wersji wymagałoby możliwości odpalenia kilku tasków jednocześnie, ale ten scheduler pythonowi afair mówiłeś, że potrafi. Może to by było dobrze. Trudno mi zdecydować bo poza torrentem to mi do głowy żaden przypadek użycia nie przychodzi ;)
  2. 'task', ok. miałem problem z wymyśleniem słówka :) W takim razie 'check', 'setup', 'task' i 'cleanup'.
  3. wolałbym zapisywać w lokacji określanej przez demona i żeby to demon o tym decydował. Tzn. ja wysyłam plik 'foo.txt', on ląduje w /tmp/test-2304234-1, a na demonie przed uruchomieniem @{file.path} zostaje podmienione na ścieżkę. Jak będzie jakiś oporny program, to można sobie samemu dopisać przed nim task 'cp @{file.path} /etc/tutaj.rc'. Głównie chodzi mi o to, żeby w konfiguracji nie określać ścieżek jeśli to nie będzie absolutnie konieczne, bo się pojawią problemy z / i C:\ itp.

Pamiętam, że rozmawialiśmy o przekazywaniu wyników jednej komendy do drugiej itp, ale teraz nie pamiętam, co z tego wyszło. ;-)

  1. No fakt, że jednocześnie nie będą działać, więc jeden stop powinien wystarczyć.
  2. Komendy są podzielone na cztery grupy. Jak chcesz to możesz wyniki sobie trzymać podzielone i zrobic inne 'czasowniki' ('task') do wyciągania ich. Ja z kontrolera wysyłam unikatowe ID tak, że wystarczy mi zwykłe 'get'. Bo jeśli 'task' ma wyciągać wyniki zarówno z 'task', jak i 'check', 'setup' i 'cleanup' to bez sensu używać słowa 'task' akurat.
  3. OK. To ja się idę pakować bo zaraz wstaję :P
rpt commented 14 years ago

Zamykam.