DS / VMMgr - notifikace o stavu SW pro uživatele - draft k zadání #373

New Issue

2019-06-12T12:10:23+02:00

Podhorecky commented

2019-06-12 12:10:23 +02:00

(Migrated from git.spotter.cz)

Toto je nárh zadání k vývoji funkčnosti notifikací.

Cíl: v minimální formě oznámit informaci o dostupnosti nového buildu VM pro stávající uživatele VM.

Rozšířený cíl: oznámit i jinou technickou informaci o stavu DS, nebo o SW a datech poskytovaných přes VM.

Diskuse:
Rozvoj a aktualizace běhového prostředí VM bude dlouhodobě na činnosti konkrétního vývojáře, tj. neděje se tak snadným a automatizovatelným způsobem. Po různých vědomých upgradech, bugfixech, testováních tedy vznikne nové sestavení VM, případně jiné změny ve službě DS. Tuto informaci by bylo vhodné oznámit dosavadním uživatelům VM.
Soudím, že to nemusí být tradičně přes e-mail konkrétnímu správci, ale spíše přímo do rozhraní VMMgr do admin sekce. Nelze vědět, kdo se stane konkrétním správcem u konkrétní VM, ale předpoklad je, že někdo jím bude. Jakmile si někdo zlikviduje vlastní VM, pochopitelně že přestane mít i notifikace.

Struktura informací:
Minimální, do budoucnosti počítat s variantou jazykové mutace. Pravděpodobně bude vycházet ze stavu verzí hlavních SW, ale nemusí být jen výhradně o verzích. Může to být i info jiného typu, jako trvalé odstranění konkrétního SW, aktualizace statických datových sad, které nejsou softwarem ale jejich dostupnost bude spravována přes DS / VMMgr jako např. mapové podklady konkrétního data, upozornění na expiraci časově závislých klíčů, certifikátů, (+cokoliv dalšího technického) Může být ve formě strukturovaného textu, tj. včetně hyperlinků, nebo zvýraznění textu.
Teoreticky může být s možností vložení URL obrázku, ale není to podstatnékomplikovalo by to frontend design.

Tento způsob oznamování by byl nepersonalizovaný, nebude obsahovat žádné citlivé údaje, ale nebude sdělován jinde než pouze přes VM.

Zadání k řešení:
Domyslet, navrhnout datovou strukturu, způsob zápisu zprávy, ukládání historie, případně nejbližší stručné roadmapy, způsob failoveru a případně potenciální standartizaci této push notifikace. V případě nedostupnosti DS by poslední info měla být čitelná v offline běžící VM.
Pokud by později došlo k přepracování a obohacení, tak aby šlo spíše o rozšíření stávající jednoduché funkčnosti, než zcela předělání této funkčnosti.

Další nápady, změny zadání, upřesnění: v komentáři zde.

Dokumentace: - popsat stručně v dokumentaci

Termín implementace: neurčen, jak vyplyne

Toto je nárh zadání k vývoji funkčnosti notifikací. **Cíl**: v minimální formě oznámit informaci o dostupnosti nového buildu VM pro stávající uživatele VM. **Rozšířený cíl**: oznámit i jinou technickou informaci o stavu DS, nebo o SW a datech poskytovaných přes VM. **Diskuse**: Rozvoj a aktualizace běhového prostředí VM bude dlouhodobě na činnosti konkrétního vývojáře, tj. neděje se tak snadným a automatizovatelným způsobem. Po různých vědomých upgradech, bugfixech, testováních tedy vznikne nové sestavení VM, případně jiné změny ve službě DS. Tuto informaci by bylo vhodné oznámit dosavadním uživatelům VM. Soudím, že to nemusí být tradičně přes e-mail konkrétnímu správci, ale spíše přímo do rozhraní VMMgr do admin sekce. Nelze vědět, kdo se stane konkrétním správcem u konkrétní VM, ale předpoklad je, že někdo jím bude. Jakmile si někdo zlikviduje vlastní VM, pochopitelně že přestane mít i notifikace. **Struktura informací:** Minimální, do budoucnosti počítat s variantou jazykové mutace. Pravděpodobně bude vycházet ze stavu verzí hlavních SW, ale nemusí být jen výhradně o verzích. Může to být i info jiného typu, jako trvalé odstranění konkrétního SW, aktualizace statických datových sad, které nejsou softwarem ale jejich dostupnost bude spravována přes DS / VMMgr jako např. mapové podklady konkrétního data, upozornění na expiraci časově závislých klíčů, certifikátů, (+cokoliv dalšího technického) Může být ve formě strukturovaného textu, tj. včetně hyperlinků, nebo zvýraznění textu. Teoreticky může být s možností vložení URL obrázku, ale není to podstatnékomplikovalo by to frontend design. Tento způsob oznamování by byl nepersonalizovaný, nebude obsahovat žádné citlivé údaje, ale nebude sdělován jinde než pouze přes VM. **Zadání k řešení:** Domyslet, navrhnout datovou strukturu, způsob zápisu zprávy, ukládání historie, případně nejbližší stručné roadmapy, způsob failoveru a případně potenciální standartizaci této push notifikace. V případě nedostupnosti DS by poslední info měla být čitelná v offline běžící VM. Pokud by později došlo k přepracování a obohacení, tak aby šlo spíše o rozšíření stávající jednoduché funkčnosti, než zcela předělání této funkčnosti. **Další nápady, změny zadání, upřesnění:** v komentáři zde. **Dokumentace:** - popsat stručně v dokumentaci **Termín implementace**: neurčen, jak vyplyne

Podhorecky commented

2019-06-12 12:10:23 +02:00

(Migrated from git.spotter.cz)

changed milestone to %3

Disassembler commented

2019-06-17 11:09:42 +02:00

(Migrated from git.spotter.cz)

oznámit informaci o dostupnosti nového buildu

Tohle je veskrze frontendová záležitost. Backend poskyuje informace o současně nainstalované verzi a o verzi na distribučním serveru. Pokud je na DS novější, zobrazí se čudlik "aktualizovat". Současně se může stát cokoliv jiného - popup, změna barvy karty aplikace, zobrazení notifikační ikonky, atd. - ale to už je všechno frontend. Pokud by se mělo odesílat oznámení jiným způsobem, například mailem, vyžadovalo by to správně nakonfigurovaný mailový server, nějaký cronjob, který by to celé zajišťoval a další opičárny přidávájící na složitosti.

Pokud Vás mate to, že každé dva měsíce stahujete nějaký OVA image, tak to se bude dít jen do té doby, dokud ta platforma, kterou vyvíjíme, nebude rock-solid stabilní. Pak už bude stačit stáhnout image jednou a pojede až dokud nedojde k nějaké velmi zásadní změně, která nepůjde protlačit instalačními balíčky. Dosud totiž nemáme úplně implementovaný systém aktualizací, takže zatím aktualizujeme způsobem "Tady si to ručně stáhni a rozbal".

neděje se tak snadným a automatizovatelným způsobem

Ale bude dít :) Nastavení základních služeb VM (bootování, fonty v konzoli, iptables firewall, nginx HTTP server atd.) je persistentní. VMMgr je pak instalován jako APK balíček z vlastního repozitáře (repo.spotter.cz/alpine/...). Takže máme v zásadě dva aktualizační kanály, které musíme hlídat. Prvním jsou samotné kontejnery, které hlídá VMMgr a při každém zobrazení instalovaných a instalovatelných aplikací stahuje aktuální informace z DS. A druhým jsou pak balíky pro Alpine distribuci hostitele, ve kterých je zahrnuto jádro OS, základní služby a prostředí pro správu VM (VMMgr).

do budoucnosti počítat s variantou jazykové mutace

To už máme z většiny implementováno taky. Opět ale, vinou vývoje a častých změn, používáme natvrdo pouze češtinu, abychom se nemuseli zdržovat překládáním a testováním pro další jazyky. Jakmile bude platforma dostatečně stabilní, objeví se ve webovém rozhraní dropdown a můžete si přepnout třeba na Xhoštinu, pokud Vám to do ní někdo přeloží. Backend na to již připraven je.

trvalé odstranění konkrétního SW

V současnosti by to fungovalo tak, že pokud je software již nainstalovaný, v rozhraní by zůstal viditelný. Pokud nainstalovaný ještě není, prostě by zmizel z výpisu aplikací. Teoreticky bychom klidně mohli dělat aktualizace ve vlnách, třeba čtvrtletně, a ke každé publikovat changelog, zobrazitelný ve VMMgr. V tom by pak bylo vypsáno, které aktualizace byly aktualizovány na které verze, které byly přidány, které byly odstraněny, jestli se změnily nějaké závislosti atd.

aktualizace statických datových sad, které nejsou softwarem

Tohle bude asi trochu větší oříšek. Hlavně to bude závislé na konkrétních aplikacích a jejich zvládání duplicitních dat. Řešil bych individuálně dle aplikace a nejspíš mimo VMMgr, protože ten by měl být jen pro správu VM a kontejnerů, ale už ne konkrétních nastavení jednotlivých aplikací a aplikačních dat.

upozornění na expiraci časově závislých klíčů, certifikátů

To je rozhodně dobrý nápad, ale opět veskrze frontedovitost. Backend jen musí poskytovat funkci, které se frontend dotáže, což v případě TLS certifikátu v současnosti již poskytuje.

V případě nedostupnosti DS by poslední info měla být čitelná v offline běžící VM

V současnosti to funguje tak, že pokud není DS dostupný, zobrazí se zpráva o jeho nedostupnosti a zároveň zmizí informace o všech nenainstalovaných balících. Nevím nakolik je užitečné zobrazovat informaci o něčem, co není momentálně dostupné a při obnovení dostupnosti nemusí být nadále platné.

Např. mám VM už půl roku offline a svítí mi na ní, že můžu instalovat CTS. Kliknu na instalaci a ta mě samozřejmě pošle do řiti, protože nemám internety. Tak tedy vítězoslavně připojím kabel a čárymáryfuk, CTS zmizí, protože se stáhne aktuální seznam aplikací, ve kterém CTS už nefiguruje, protože ho Spotter před dvěma měsíci rozkázal vygumovat. V takovém případě mi přijde intuitivnější zobrazovat jen to, s čím můžu v daném okamžiku skutečně manipulovat a spolu s tím tam mít tlustou červenou hlášku, že ten zbytek nevidím, protože jsem offline.

> oznámit informaci o dostupnosti nového buildu Tohle je veskrze frontendová záležitost. Backend poskyuje informace o současně nainstalované verzi a o verzi na distribučním serveru. Pokud je na DS novější, zobrazí se čudlik "aktualizovat". Současně se může stát cokoliv jiného - popup, změna barvy karty aplikace, zobrazení notifikační ikonky, atd. - ale to už je všechno frontend. Pokud by se mělo odesílat oznámení jiným způsobem, například mailem, vyžadovalo by to správně nakonfigurovaný mailový server, nějaký cronjob, který by to celé zajišťoval a další opičárny přidávájící na složitosti. Pokud Vás mate to, že každé dva měsíce stahujete nějaký OVA image, tak to se bude dít jen do té doby, dokud ta platforma, kterou vyvíjíme, nebude *rock-solid* stabilní. Pak už bude stačit stáhnout image jednou a pojede až dokud nedojde k nějaké velmi zásadní změně, která nepůjde protlačit instalačními balíčky. Dosud totiž nemáme úplně implementovaný systém aktualizací, takže zatím aktualizujeme způsobem "Tady si to ručně stáhni a rozbal". > neděje se tak snadným a automatizovatelným způsobem Ale bude dít :) Nastavení základních služeb VM (bootování, fonty v konzoli, iptables firewall, nginx HTTP server atd.) je persistentní. VMMgr je pak instalován jako APK balíček z vlastního repozitáře (repo.spotter.cz/alpine/...). Takže máme v zásadě dva aktualizační kanály, které musíme hlídat. Prvním jsou samotné kontejnery, které hlídá VMMgr a při každém zobrazení instalovaných a instalovatelných aplikací stahuje aktuální informace z DS. A druhým jsou pak balíky pro Alpine distribuci hostitele, ve kterých je zahrnuto jádro OS, základní služby a prostředí pro správu VM (VMMgr). > do budoucnosti počítat s variantou jazykové mutace To už máme z většiny implementováno taky. Opět ale, vinou vývoje a častých změn, používáme natvrdo pouze češtinu, abychom se nemuseli zdržovat překládáním a testováním pro další jazyky. Jakmile bude platforma dostatečně stabilní, objeví se ve webovém rozhraní dropdown a můžete si přepnout třeba na Xhoštinu, pokud Vám to do ní někdo přeloží. Backend na to již připraven je. > trvalé odstranění konkrétního SW V současnosti by to fungovalo tak, že pokud je software již nainstalovaný, v rozhraní by zůstal viditelný. Pokud nainstalovaný ještě není, prostě by zmizel z výpisu aplikací. Teoreticky bychom klidně mohli dělat aktualizace ve vlnách, třeba čtvrtletně, a ke každé publikovat changelog, zobrazitelný ve VMMgr. V tom by pak bylo vypsáno, které aktualizace byly aktualizovány na které verze, které byly přidány, které byly odstraněny, jestli se změnily nějaké závislosti atd. > aktualizace statických datových sad, které nejsou softwarem Tohle bude asi trochu větší oříšek. Hlavně to bude závislé na konkrétních aplikacích a jejich zvládání duplicitních dat. Řešil bych individuálně dle aplikace a nejspíš mimo VMMgr, protože ten by měl být jen pro správu VM a kontejnerů, ale už ne konkrétních nastavení jednotlivých aplikací a aplikačních dat. > upozornění na expiraci časově závislých klíčů, certifikátů To je rozhodně dobrý nápad, ale opět veskrze frontedovitost. Backend jen musí poskytovat funkci, které se frontend dotáže, což v případě TLS certifikátu v současnosti již poskytuje. > V případě nedostupnosti DS by poslední info měla být čitelná v offline běžící VM V současnosti to funguje tak, že pokud není DS dostupný, zobrazí se zpráva o jeho nedostupnosti a zároveň zmizí informace o všech nenainstalovaných balících. Nevím nakolik je užitečné zobrazovat informaci o něčem, co není momentálně dostupné a při obnovení dostupnosti nemusí být nadále platné. Např. mám VM už půl roku offline a svítí mi na ní, že můžu instalovat CTS. Kliknu na instalaci a ta mě samozřejmě pošle do řiti, protože nemám internety. Tak tedy vítězoslavně připojím kabel a čárymáryfuk, CTS zmizí, protože se stáhne aktuální seznam aplikací, ve kterém CTS už nefiguruje, protože ho Spotter před dvěma měsíci rozkázal vygumovat. V takovém případě mi přijde intuitivnější zobrazovat jen to, s čím můžu v daném okamžiku skutečně manipulovat a spolu s tím tam mít tlustou červenou hlášku, že ten zbytek nevidím, protože jsem offline.

Podhorecky commented

2019-06-17 20:51:11 +02:00

(Migrated from git.spotter.cz)

ok, díky za komentář... k tomu poslednímu stavu a informování: Ok, rozumím námitce a pravděpodobně vyhoví status OFFLINE. Měl jsem jen takovou tu hrůzu ze situací, kdy si použivatel zvykne na online že to ani nevnímá. Při náhlém offline najednou zjišťuje, že nejen že klikání nepomáhá, ale že mu všechno co bylo online zmizelo a i primitivní informace, které byl líný si pamatovat jsou fuč, protože je offline.

Tenthle stav samože nemusí být vážný... přemýšlím jestli může být nějaká konkrétní kritická situace která by adminovi zkomplikovala život natolik, že by si přál mít tuto info nějak offlinovanou.

aktualizace stiatických datových sad

tady jsem asi přednostně myslel třeba ty částečně stažená OSM data a to bude možná vymyšlené již někým jiným. MapTiler to právě nějak řešil, poznamenal jsem si. Možná že to bude jediný příklad dat o které půjde při aktualizacích do vlastní VM.
Možná by se měl z tohoto procesu DS rovnou vyloučit, pokud by OSM data byla uživatelsky stažitelná rovnou ze zdrojů. (Např. při prvním setupu si admin zvolí jeden nebo více regionů downloadu, ten stáhne, tím se stanou mapy region(ů) lokální. Při potřebě aktualizovat mapy se vyšle dotaz rovnou na OSM, nebo jiný MapTiler, buhvíjak)

Všechna ostatní data by byla zprostředkována jen těmi konektory. Nemusí to být nutně přímo ve VMMgr, možná na to vznikne samostatný tool, nebo datamanager, zatim nevim.

jinak to ostatní chápu jako frontendovou záležitost, ledaže byste měl nějako zásadní námitku, kterou bychom museli vyřešit dříve, než frontend.

ok, díky za komentář... k tomu poslednímu stavu a informování: Ok, rozumím námitce a pravděpodobně vyhoví status OFFLINE. Měl jsem jen takovou tu hrůzu ze situací, kdy si použivatel zvykne na online že to ani nevnímá. Při náhlém offline najednou zjišťuje, že nejen že klikání nepomáhá, ale že mu všechno co bylo online zmizelo a i primitivní informace, které byl líný si pamatovat jsou fuč, protože je offline. Tenthle stav samože nemusí být vážný... přemýšlím jestli může být nějaká konkrétní kritická situace která by adminovi zkomplikovala život natolik, že by si přál mít tuto info nějak offlinovanou. > aktualizace stiatických datových sad tady jsem asi přednostně myslel třeba ty částečně stažená OSM data a to bude možná vymyšlené již někým jiným. MapTiler to právě nějak řešil, poznamenal jsem si. Možná že to bude jediný příklad dat o které půjde při aktualizacích do vlastní VM. Možná by se měl z tohoto procesu DS rovnou vyloučit, pokud by OSM data byla uživatelsky stažitelná rovnou ze zdrojů. (Např. při prvním setupu si admin zvolí jeden nebo více regionů downloadu, ten stáhne, tím se stanou mapy region(ů) lokální. Při potřebě aktualizovat mapy se vyšle dotaz rovnou na OSM, nebo jiný MapTiler, buhvíjak) Všechna ostatní data by byla zprostředkována jen těmi konektory. Nemusí to být nutně přímo ve VMMgr, možná na to vznikne samostatný tool, nebo datamanager, zatim nevim. jinak to ostatní chápu jako frontendovou záležitost, ledaže byste měl nějako zásadní námitku, kterou bychom museli vyřešit dříve, než frontend.

Podhorecky commented

2019-06-18 08:43:10 +02:00

(Migrated from git.spotter.cz)

jinak ten naznačený způsob co největší systematizace updatů je zajímavý, nepřehlédl jsem ho, jsem zvědavý a nedokážu to prozatím komentovat :)

Disassembler commented

2020-06-20 18:03:59 +02:00

(Migrated from git.spotter.cz)

moved to Spotter-Cluster#60

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Spotter-Cluster/Spotter-VM#373