VM - metadata kontejneru #305
Labels
No Label
app-basic
app-ckan
app-crisiscleanup
app-cts
app-decidim
app-dhis2
app-frontlinesms
app-gnuhealth
app-kanboard
app-mifosx
app-motech
app-odoo
app-opendatakit
app-pandora
app-sahana
app-seeddms
app-sigmah
app-taarifa
app-ushahidi
critical
CZ
documentation
Doing
enhancement
GMaps
info
Mapbox
needinfo
new-app
OSM
performance
QGIS
regression
suggestion
To Do
upstream
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Disassembler/Spotter-VM#305
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Nápad + dotaz: Bylo by vhodné a praktické, aby každý kontejner, který se rozhodneme zprovoznit a distribuovat do VM měl u sebe nějaká metadata o tom jaký je, případně jak náročná aplikace uvnitř číhá, případně jaký jiný kontejner kamarádí s tímto kontejnerem a podobně?
Cílem je aby tuto info měl admin na očích ve fázi konfigurace a dalo mu to vhled na situaci jak má pracovat s vyhrazenými systemovými prostředky atd.
brainstorm k diskusi:
pokud někde něco podobného existuje, lze se inspirovat? Alespoń částečně?
metadata formálně nemusí být kompatibilní s nějakým paformátem, ale ideálně aby byla ve zpracovatelných datech typu XML, nebo JSON, nebo nevim? Nebo staří prostě mít je v DB někde?
data která vidí admin by byla např: velikost kontejneru, paměťové nároky, výkonová náročnost aplikace v nějakém jednoduchém měřítku, potenciální nafukovatelnost vlastními daty (?), závislost na jiném kontejneru (?) mobilní nebo jiní klienti? Jazykové verze které lze čekat (?) ...
co ještě může být užitečnou meta-informací o kontejneru? (nemyslím tím opakovat jeho kompletní SW obsah a komponenty, to by bylo asi náročný a zbytečný)
mělo by se do metadat narvat info o licenci, nebo to spíš řešit jinak?
mělo by se do metadat narvat prakticky vše co je teď v jeho boxiku ve viditelném portálu? Tedy vlastně i obecný popis, název, logo? (možná to tak dává smysl, nevím)
info o výměnných datových formátech které by mohly adaptovat jiné kontejnery?
získávat nějakou pasívní zpětnou vazbu o funkčnosti kontejnerů? (nedělat z toho lajkovací sociální síť ani udělování bludišťáků, ale spíš něco technicky praktického. (?)
kompetenci ve vzniku metadat a editaci by měl kdo? Předpokládám že zařazení aplikace do nabídky by byl nějaký postupný proces spuštěný řiditelem tohoto cirkusu, čili objevování, diskuse s pachatelem o připuštění, zkoumání, nadávání, zkoušení, ladění, až po konečné rozhodnutí co s tím... ?
vznik metadat by se psal někde v interface distribučního serveru?
Když tak zkoumám současný stav, tak modularita tohohle kočičího dortu může být fakt super. Předpokládejme, že až se projekt stane dospělým, mohl by mít v nabídce distribučního serveru odhadem nízké desítky aplikací, ale určitě ne stovky. Šel bych raději směrem zvyšování kvality a provazování workflow, než k množení kdečeho. Z nabízených apps nich by se dalo vybrat co by koncový uživatel potřeboval a Měl by na míru svoji VM.
Byla by metadata k něčemu? Nebo to je příliš nerdy?
Termíny realizace zatím neřešme. Jsou to dotazy
Pokud se bavíme o technických metadatech, ty máme v současnosti ve formátu JSON v rámci balíčkovacícho systému. Obsahují mimo jiné
Velikost nerozbaleného archivu máme. Dále můžu poskytnout velikost v rozbaleném stavu (nebude přesná kvůli závislostem) anebo nějaká doporučení (min. konfigurace 123 MB disk, 234 MB RAM, doporučená konfigurace 234 MB disk, 345 MB RAM atd.)
To určitě můžeme a asi by to bylo i vhodné. Může se zobrazovat v nějakém informačním popupu společně s popisem, velikostí a spol. Pro jednoduchost třeba jen zkratka (MIT/GPL/LGPL/Apache) s odkazem ven na konkrétní licenční soubor.
O tom jsem přemýšlel už při návrhu aplikace a IMHO to nedává smysl. Budu teď znít jako F&B, ale ta aplikace je modulární, založená na dobře známých pythonovských frameworcích Werkzeug a Jinja2, takže ten xicht, který uvidí koncový uživatel si každý může relativně jednoduše ohnout podle svých potřeb. Náš xicht má ty boxíky natvrdo zadané v šabloně a je u nich jen podmínka, že se mají zobrazit, pokud je aplikace nainstalovaná a a spuštěná. Nejsme (a ani případní jiní osvojitelé) tedy svázání nějakým rozhodnutím, že hlavní strana musí být boxíky a neřešíme problémy jak se potýkat se situacemi
Řesil bych v dokumentaci
Ostatní dotazy mi přijdou, že cílí spíš na nějaká uživatelsky čitelná metadata, která jsou spíše subjektivní a použitelná jen pro konkrétní účely nasazení, takže to bych nechal na konkrétním ohybateli frontendu, jaká data chce mít a vidět. Ten JSON, který máme v balíčkovacím systému, je agnostický. Vyžaduje pouze, aby existovaly ty informace uvedené v prvním bodu a pokud do definice balíku někdo připíše nějaké další páry klíčů a hodnot, prostě je při instalaci vezme z distribučního serveru a překlopí do lokálního souboru a je mu úplně jedno, jestli je to pohádka o ovčí babičce nebo nějaká životně důležitá a technicky relevantní informace. Přiohybatel pak jen v kódu zkontroluje, že pro ten daný balík klíč existuje a může jej zobrazit tak, jak uzná za vhodné.
ok, ... díky. Zatím to vidím, že nějaká metadata potřebujeme. Minimum asi to, co jste naznačil. Formu zjevení budeme řešit až dojde na frontend :)
mentioned in issue vmmgr#1
Tohle issue tedy zavírám s tím, že co se systému týče, metadata mohou být úplně jakákoliv, podle vkusu každého soudruha. Frontend k nim má plný přístup a je jen na domluvě mezi baličem a frontenďákem, jaká metadata jsou očekávána a jak se budou zobrazovat.
Základní metadata, která jsou v tomto okamžiku používána VM manažerem a balíkovacím systémem jsou shrnuta v dokumentaci k balení kontejnerů. Další diskusi o přidávání dalších metadata pak případně otevřeme v podprojektu VMMgr.
closed