Vlákno názorů k článku Novinky v Knot Resolveru 6.x: správce procesů a přehlednější konfigurace od Vantomas - Takže i když mám systemd distro, tak se...

Takže i když mám systemd distro, tak se jako manager bude používat supervisord? Přijdu tedy o možnost hlídat jednotlivé procesy přes systemd unity? Budu si muset do monitoringu implementovat hlídání procesů přes supervisor? CPUAffinity pro jednotlivé kresd nastavím kde?

Pokud to správně počítám, tak to bude již potřetí, kdy budu opět překonfigurovávat celý cluster a pak další půlrok odchytávat nuance. Jak dlouho bude vývojáři podporován běh bez manažeru a s Lua konfigurací?

Systémy se systemd zůstávají jako primární use case. Stejně jako jiné démony teď budeme mít (v defaultu) pouze jednu systemd unitu, která bude obsahovat všechny části Knot Resolveru. Procesy uvnitř toho celku bude spravovat supervisord, úplně identicky jako na nasazeních bez systemd.

Nevím jestli u jiných démonů monitorujete jednotlivá vlákna procesů a nastavujete z vnějšku jejich afinity. Jinak ty afinity jednotlivých procesů, to by mohl být dobrý námět na doplnění konfigurace. Je to zase věc, která bude dávat smysl i bez systemd. Budeme rádi, pokud nám popíšete své představy o nastavení afinit, ideálně s vysvětlením co Vás k tomu vede, ale prosím jiným kanálem než tady, vizte https://www.knot-resolver.cz/support/free/

5.x bude dostávat minimálně důležité bezpečnostní aktualizace, minimálně celý rok 2024. Dál se uvidí dle situace, včetně zpětné vazby jako tato.

6.x s manažerem podporuje přidávání lua skriptů - a lua API zůstalo z většiny nezměněno. (Manažer generuje tohle lua z YAML.) Běh bez manažeru jako doteď bude v 6.x fungovat, ale v našich balících, dokumentaci a podpoře bude preferován manažer s YAML.

Příliš často se stávalo, že to lua lidi popletou - a sice je výsledkem zcela korektní lua program, ale nedělá to co čekají a oni netuší proč. Například neexistující identifikátor se v lua vyhodnotí jako nil, což je na mnoha místech zcela korektní hodnota...

Systémy se systemd zůstávají jako primární use case.

Z vašeho pohledu možná zůstává systemd jako primární use-case, ale vlastně ho zcela kastrujete a vracíme se někam do doby tranzice Debianu ze SysV, kde systemd volal "/etc/init.d/knot-resolver start" a o stavu, kondici a běhu samotné služby už něvěděl zhola nic.

Nevím jestli u jiných démonů monitorujete jednotlivá vlákna procesů

Ano, u služeb, které chci nastavit a pak na to "několik let nesáhnout" hlídám vše co jde, protože pak když se něco řeší, jde z těch dat zjistit i něco zpětně. U kresd mám navíc zkušenost, že to trpělo na pády nebo memory leaky a tak sledování obsazené paměti, uptime procesů, retval a důvod restartu, bylo vždy takové jedno z prvních varování, že se po update něco nepodařilo a je čas to opravit dřív, než si někdo všimne, že je to rozbitý.

Nyní se přesouváme někam k Postfixu, kde si jeho manager taky naspouští hromadu procesů, které si můžu nějak monitorovat, ale když se tam začne něco dít, musím jít kutat do spoustu různých zákoutí a co ta konkrétní věc vypsala do stderr ani nikde pořádně nezjistím, protože si někde musím povolit verbose, který zase nemůže být povolený trvale v produkci.

Jinak ty afinity jednotlivých procesů, to by mohl být dobrý námět na doplnění konfigurace.

Úplně přehnaně poslední kapky výkonu z toho neždímu, ale když se to polechtá dnstracem a chci dostat latence co nejníž to jde, tak affinita je jasná volba.

5.x bude dostávat minimálně důležité bezpečnostní aktualizace, minimálně celý rok 2024.
...

Pohnutkům proč manažer, i proč se zbavit Lua rozumím, i z toho vidím kam a proč to takhle směřujete a tak nebudu jen zbytečně brečet, že chci zpátky svůj spacebar heating, ale přesto si musím postěžovat, že v začátku to bylo postavené na nějakých vlastnostech a ideích, o které se s každým major updatem přichází.

Možná jsem to na začátku špatně pochopil a váš cíl nebyl projekt, který se bude krásně provozovat na anycast clusterech, kde to běží v nějakém časem odladěném prostředí a kde jakákoliv větší změna způsobí velkou bolest, ale uspokojit Pepíka, který si přečetl, jak je Turris super a pak sáhne tam kam nemá a nepozná rozdíl mezi kulatou a hranatou závorkou.

Sledování logů je možné úplně stejně jako dosud.

Velká nasazení jsou pro nás rozhodně velmi důležitá. Celkem dost se věnujeme výkonu. Sami anycast cluster s Knot Resolverem provozujeme už dlouhou řadu let. Na jejich konfiguraci nebylo třeba sáhnout roky, občas tak jeden řádek změny, dokud se neupgradoval hardware. Teď přichází ještě mnohem větší nasazení, DNS4EU. Také existují velcí ISP používající Knot Resolver. Zatím jste první z velkých nasazení, kdo si na tohle stěžuje.

(Na druhou stranu, naši podporu si neplatíte, takže popravdě prioritizujeme spíše přání těch co ano.)

Noooo... to ze bylo na tom odvr anycastu vzdy bezproblemove bych rozhodne netvrdil - Zdenek to tu nasledne samozrejme vysvetlil, cim to bylo... ale navenek to vzdy uplne rock-stable to nebylo. A vznikaly z toho samozrejme lidsky neprijemne situace, kdy vam pak pribuzenstvo vola, ze jim nefunguje internet - protoze kvuli chybam v DoH to neresolvovalo projistotu vubec... samozrejme ultimatnim resenim tady je multi-instance, kdy smrt jednoho rozhrani nezabije vsecko (a v 6.x to zachovane je, takze vlastne dobry).

Nyní se přesouváme někam k Postfixu, kde si jeho manager taky naspouští hromadu procesů, které si můžu nějak monitorovat, ale když se tam začne něco dít, musím jít kutat do spoustu různých zákoutí a co ta konkrétní věc vypsala do stderr ani nikde pořádně nezjistím, protože si někde musím povolit verbose, který zase nemůže být povolený trvale v produkci.
Tohle je trochu obecnější problém, že spousta služeb se skládá z více procesů (nejen Postfix, i qmail, aplikační nebo databázové servery, třeba i Apache když vytváří procesy pro obsluhu požadavku nebo pro CGI) – a vlastně každá aplikace si to pak musí řešit sama. Správnější by bylo, kdyby na tom měl nějakou podporu přímo systemd – jenže pak by zase příslušná aplikace byla závislá na systemd. Nebo by musela mít dva režimy, vlastního správce procesů nebo použít externí správce procesů jako systemd, což by samozřejmě byla zase komplikace pro vývoj.

Vzhledem k tomu, že se spousta věcí přesouvá do kontejnerů, kde je to z pohledu systemd nebo jiného správce služeb také jeden proces, který si možná spustí své další procesy, čekal bych spíš, že se půjde cestou monitoringu. Tedy že ty podřízené procesy nebudou přímo řízené systemd, ale budou moci být alespoň nějak monitorované (včetně využití paměti, pádů apod.).