SE - Configuration wizard #311
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#311
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?
žeby v Sahaně vytvořili kouzelníka?
e779ce7c73to by asi bylo pěkné... později doufám půjde prozkoumat
Mohu poprosit o jednu věc s termínem? Na Silvestra budu pracovně v Č. Krumlově, kde budu mít čas se věnovat VM. mohl byste do té doby refreshnout VM SW ke stažení - tj. co lze jednoduše aktualizovat? Stav rozpracovanosti nehraje roli. Pokud by v Sahaně bylo něco nového k vidění, tak fajn.
changed title from SE - Configuration wiz{-z-}ard to SE - Configuration wizard
mentioned in issue #168
No to bude celkem problém, protože jste v https://git.spotter.cz/Spotter-Cluster/vmmgr/issues/1 vymyslel, že se bude používat nějaké prověřené řešení, takže jsem na základě toho transformovat instalátor na Alpiňácký nativní APK. Takže to, co máte na Vámi dostupné virtuálce už použít nepůjde a to, co co mám rozpracované ještě potřebuje upravit provázání ze strany frontendu. Můžu kopnout do vrtule, ale jestli to dám za dva dny dohromady, to asi slíbit schopen nejsem. (A že takový požadavek schováte do issue o něčem nesouvisejícím, to je taky dobrá zákeřnost)
Na Sahaního konfiguračního kouzelníka kouknu, ale vidím, že vytváří
000_config.pya teprve pak Sahanu instaluje, což jde proti idei předinstalovaných a předkonfigurovaných kontejnerů.Aha, jasný... no tak neva, tohle je pro mne nová informace, tak udělejte to, co máte v plánu, já to nehrotim. A uděláme to až pak.
Napadlo mne, jestli by něčemu pomohlo, že by výběr modulů přes Configuration wizzard šel nastavit ještě před instalací kontejneru Sahany?
Sahana by tedy byla zatim jediná aplikace, která už by se instalovala s takovým administrátorským přednastavením.
Předpokládám, že SE bude dál rozvíjet různé moduly a jak už jsem debatovali na počátku, tak pro uživatele není cílem mít všechny moduly naráz... (to je cíl akorát pro mne, coby developera abych vůbec viděl jestli fungují).
V balíku by samože byla Sahana komplet, ale první setup už jen s vybranými moduly.
... lze tedy o tom takto přemýšlet, co se týče instalační a konfigurační procedury? Pomohlo by nám to k tomu, aby se dal využít wizzard a náš balíčkovač zároveň?
mentioned in issue #410
teď jsem objevil že Configuration wizzard je přímo v GUI na setupu administrace https://sahana-demo.spotter.dasm.cz:8443/eden/setup/deployment/1/instance/1/wizard?page=1
ale netušim jestli je to jeho maximum, nebo i tento Wizzard má nějaký vlastní setup... zatim se můžu porozhlédnout co to vlastně dělá.
aha... zak zaškrtnutím modulů to vyrobilo ticket.
Naše Sahana se od Demo liší v tom, že v menu Administration máme
zatímco Demo:
mentioned in issue #421
Pád výše opraven v upstreamu a reflektován u nás (příbuzný problém s naším #421).
K funkci Setup wizarda samotného - Je to opět trochu vyšší dívčí, takže se pokusím shrnout a vysvětlit to nejpodstatnější.
Možná jste již někdy zaslechl o záležitosti zvané "Ansible". To je takové velmi mocné automatizační udělátko pro různý provisioning virtuálek, instalaci aplikací, úprav konfigurací a všelijakých jiných IT opičáren. Je to nástroj psaný v pythonu a na každé prdnutí má hromadu modulů. Práce s ním probíhá tak, že se vytvoří sled kroků nebo požadovaných stavů v tzv. playbooku a ten playbook se pak spustí a ono to udělá, to co to udělat má. Něco stáhne, nainstaluje, aktualizuje, nastaví, smaže atd. Užitečnost nastává, pokud sled těchto událostí potřebujete udělat na stovce mašin zároveň anebo třeba na jedné mašině stokrát za den.
Takže když Fran vytvářel playbooky pro eden_deploy, pro nasazení Sahany na různých cloudových platformách, napadlo ho "Hmmm, a proč to, co jsem právě vyrobil, nepoužít i pro rekonfiguraci živých instancí?" a spíchl dohromady nějaký proof-of-concept.
To ale přináší několik problémů:
Takže sečteno podtrženo, myšlenka je to zajímavá, ale i přesto že už má přes 5000 řádek kódu je v úplném zárodku a pro naši platformu a náš template tak, jak jej v současnosti máme, není použitelná. Pokud to vezmu z hlediska systémové administrace, tak je to přímo noční můra, protože takto aplikace získá možnost modifikovat sama sebe, což může vyústit ve velmi zajímavé a neopravitelné stavy (výmaz a reinstall v tomto případě nepovažuji za opravu :) ).
Super.. díky moc za vysvětlení :) Mě se to hned zdálo trochu podezřelé, zejména i související možnosti jak z rozhraní vypínat - zapínat vlastní deployment. :)
No, takže pro mne závěr: Já se tím zabývat nebudu, po Vás to taky nebudu chtít... vhodnější vidím náš postup. Ostatně... cloudové deploymenty Sahany bychom taky nemuseli řešit, protože s naší formou VM bych je určitě nerozvíjel. To ať si řeší oni.
V dokumentaci bych potřeboval krátké věty typu asi: Toto je funkčnost kterou v rámci VM nedoporučujeme používat. (cokoliv detailního můžete doplnit jak uznáte že je dobré zaznamenat, nebo odkázat hyperlinkem někam na web)
Deploymenty neřešme, ale u bodu 3. jste psal o tom že tohle tedy je taková ukázka od Frana, nicméně asi by měla s tím co je, fungovat, ne?
Akorát hlásí, že na Demo Instanci neni doinstalovaná komponenta PyYAML https://pypi.org/project/PyYAML/
pokud by se tak stalo, je možné to považovat za funkční? Tj. po překlikání se změní ta jedna konkrétní věc. Zkusíme i na instanci Spotter?
Tak jsem si na Vaše naléhání vyhradil ještě jedno odpoledne na pokusy o zprovoznění Setup modulu. Ponořil jsem se todo toho vcelku nezištně a začal zkoumat třeba proč Sahana při poklikání nastavení modulů po opravách předcházejících problémů teď hlásí úspěch i přesto, že se nic nestane a tak. Konečně jsem naprosto dokonale pochopil popis všech ústředních hrdinů Lovecraftových povídek a naplno se do nich vcítil. Postupným pročítáním toho, jak celý ten setup modul funguje a jak je vymyšlený celý sahana_deploy podprojekt jsem objevoval čím dál tím neuvěřitelnější, děsivější a nepopsatelnější konstrukce, snažil se pochopit jak zvrácený mozek něco takového mohl vymyslet a proč by to vůbec dělal, až jsem nakonec připadl na tento opis z Necronomiconu, vykřikl hrůzou, počítač rozpustil v kyselině a zakopal v lese. Teď už mi zbývá jen všechny, kteří se pokusí jít v mých stopách, varovat, aby na to místo nikdy nechodili.
Nejspíše Vás zajímá, co ten řádek znamená. Inu, to je nastavení pro nástroj "sudo", kterým se dá zvýšit oprávnění obyčejného uživatele. Tento nástroj mimochodem v kontejneru vůbec nemáme nainstalovaný, protože jde tak trochu proti filozofii toho, proč vůbec kontejnery používat. No a ten jeden krásný řádek přiděluje uživateli, pod kterým jede Sahana, oprávnění k tomu spouštět jakýkoliv příkaz na celém systému, aniž by byla potřeba nějaká druhotná autentizace. To není jen nejhorší noční můra každého sysadmina, to je skutečná prastará zelená, vlhká, okřídlená nestvůra plná očí a chapadel. Ph'nglui mglw'nafh ALL=(ALL) NOPASSWD:ALL R'lyeh wgah'nagl fhtagn.
Zbytek je ještě horší, než jsem původně vůbec předpokládal. Ansible playbooky, jež by měly být relativně univerzálními, jsou psány takovým způsobem a jsou jim předávány, případně natvrdo kódovány takové parametry, že budou fungovat pouze na konkrétním operačním systému, kde je Sahana nainstalována s konkrétními komponentami a závislostmi, konkrétními konfiguračními soubory s konkrétním obsahem a v konkrétním umístění. Nedokonalou paralelou by bylo něco jako kdybyste si koupil kapalinu do ostřikovače a pak zjistil, že bude fungovat jen na zadní stěrač v červených Škodách Oktáviích TDI vyrobených v roce 2017.
Jo a už jsem se někdy zmínil, že Sahana, kterou instalujeme není vůbec ta, na kterou jsou všechny ty skripty stavěné? Ona totiž ještě existuje odnož eden-stable, kterou ty skripty všechny instalují a očekávají. Jak moc se od té originální verze liší netuším, ale mám velmi silné tušení, že to slovo "stable" rozhodně nebude mít význam, který se od něj dá očekávat.
Takže se nabízí tři scénáře.
Kterou cestou se tedy vydáme?
meh...
LOL
Debilové!
Varianta 1) Děkuji mnohoX!
/achjo/
Váš průzkum považuji v souvislosti s bezpečností za poměrně důležitou přidanou hodnotu naší instance Spotter. Teď jen nevím, jestli to bezpečnostní odhalení nějak kulantně sdělit autorům...(?)
Jsem přesvědčen, že o tom vědí, tohle se nestane jen tak náhodou nebo z nedbalosti. Resp. z nedbalosti by se to stát mohlo v případě, kdy Fran mávl rukou a řekl "Ále, seru na to. Vypisovat 20 různých cest, umístění a příkzů se mi teď nechce, tak tam jebnu všechno. Ono se to časem doladí." Takže v tomto případě jsem si celkem jist, že by odpovědí bylo opět "Máte úplnou pravdu. Pošlete PR."
chápu...
Navrhuji toto: soustřeďme se na věci, které jsou v rámci našich možností a vaší dobré vůle řešitelné reportem, nebo nanejvýš "drobným PR" ... nenutím vás do žádných velkých přestaveb jejich architektury. Diskuse o těchto hororech - nechám na vašem dobrém rozmaru... Vím, že diskutovat s nimi o návrhu SW je relativně ne-efektivní. Úplně by stačilo nemít ty zjevné bugy.
Pro instanci Spotter budou některé věci řešitelné prostým odstraněním z nabídky funkcí + pár slov v dokumentaci. Aby bylo jasné že to nezmizelo náhodou, ale záměrně. (to, že na těch pár slovech jste vynaložil spoustu hodin a svou zkušenost, vím moc dobře)
Protože jsem tvor šťouravé povahy, rozjel jsem si Debianí kontejner a zkusil si oťukat variantu 3. Samozřejmě ani eden_deploy nefungoval na první dobrou a musel jsem ho trochu poohýbat, aby mi v kontejneru sekal dobrotu, ale na fyzické mašině nebo čistě ve VM by to nejspíš jelo i bez úprav. Patch i poznámky jsou prozatím na GitHubu ve Vašem forku ve větvi custom. Ta idea v zásadě není špatná. Je evidentní, že celá paráda má sloužit téměř výhradně pro nasazení v cloudu a všechny ty funkce a playbooky jsou v tomto dost jednoúčelové, ale ohledně zpracování jsem už fňukal v předchozím příspěvku, takže teď trochu z druhé strany.
Sahana se tím dá nainstalovat s template setup. To je úplně holý template bez jakýchkoliv modulů, tedy mimo modulu setup, samozřejmě. Tento template slouží jako jakýsi "Ovládací panel" skrze který se dají sázet a v omezené míře i ovládat další deploymenty - zastavovat, spouštět a upravovat některá základní nastavení v souboru 000_config.py, např. Google API klíč, email odesílatele a tak. Všechny tyhle detaily a rozhraní pro správu jsou viditelné i v Demo a Spotter instanci (pár screenshotů níže, aby bylo úplně jasné, o čem mluvíme. Na Demo instanci tady a tady). Ovládání cizích instancí někde v cloudech a na cizích počítačích se ale rozchází s ideou s jakou Vaši VM vytváříme, takže konkrétně tuhle featuru pro vytváření dalších instancí bych nechal nefunkční s tím, že pokud by někdo o takový multi-deployment měl skutečně zájem, tak bychom něco takového uměli taky poskytnout.
Vytvoření nové lokální instance mi bohužel selhalo, ale to bylo tím, že nová instance si stahuje čerstvý obsah repozitáře sahana_deploy z upstreamu a tím pádem nepoužije ten náš napatchovaný a selhává na věcech, které už jsem si přiohnul. Tohle by bylo případně řešitelné systémově, kdyby to někdy bylo potřeba. Takže jsem si "plnou" instanci pustil ručně přes playbooky a vytvořil jsem to samé, co u nás máme jako Demo (t.j. default template). Na té jsem si v setupu poklikal ty moduly těmi radiobuttony, po kterých pořád tak mlsně pokukujete, potvrdil a... nestalo se vůbec nic. Bylo to takové velmi antiklimaktické. Ono to totiž celé funguje tak, že Ansible upraví konfigurační soubor, provede případné úpravy v databázovém schematu a naplánuje restart instance za jednu minutu, protože si nemůže restartovat pod prdelí server na kterém ty akce zrovna vykonává (ono teda jako může, ale je tam tolik abstrakce, že je to takhle jednodušší). Uživatel tedy dostane zelenou hlášku o tom, že hotofka, ale ještě minutu nehotofka. Minutu, při které máme Schrodingerovu instanci, protože schema a konfigurace už jsou upravené a čeká se na restart, takže jakákoliv další změna může instanci rozbít (resp. asi ne celou instanci, ale nějaké zrovna rozklikané workflow). Na druhou stranu chápu, že tohle není něco, co by se provádělo každý den a co by mohl dělat každý uživatel, takže s příslušnou dokumentací je to asi únosné. Nic navíc nebo nic jiného, co bychom už neviděli v těch templatech a modulech není.
Ještě zkusím jemně a nenásilně prozkoumat tu variantu dvě. Zrovna ta možnost měnit API klíče a nastavení mail serveru v 000_config.py mi z hlediska sysadminiování připadá zatraceně užitečná a kdyby nám fungovala, vytrhla by nám malinký trn z paty s nutností nastavovat tyhle věci přes VMMgr.
Ten sudoers hajzl zpřístupňující systému všechno s rootovskými právy skutečně je záměrný. Našel jsem v těch playboocích noticku, kde je toto bez jakéhokoliv ostychu explicitně zmíněno.
Jo a říkal jsem, že by to zvětšilo velikost instance o 400 %? Tak to jsem zas kecal. Zvětšilo by ji to o 625 %.
Hm... zajímavé...
pokusím se k tomu přidat můj -nesysadminový- pohled, kterým bych to chtěl nějak doplnit. Tedy nerozporuji výše řečené :)
Snažím se chápat, že jedna z nutných potřeb Sahany je nasazování na různé cloudové služby. A proto tam F+D rozjeli tenhle tyjátr se všemi těmi Amazony a podobně. Jako jo, fajn. Když jim to do pár let bude fungovat se vším co chtějí, tak gratulki.
Druhá věc, kterou vnímám, je jakási nevyřčená tendence, která se s těmito komerčními cloudovými službami vynořuje. Tou je extremní závislost na cloudu, který fakticky kontroluje "někdo jiný", nebude to dělat jako charitu.
A taky existuje relativně ne-nulová zranitelnost na síti v "poslední míli" . Přestože cloud umí běžet na 99,95% i při jaderném výbuchu, tak poslední míle to může srazit na hodně nízké procento když tu zrovna napršelo do antény ISP a pak je po žížalkách. A tak se pak všechny fantastické vlastnosti cloudu rozplynou. Můj iracionální strach se cloudy přímo zvětšuje, než aby se menšil.
Taky proto jsem se pustil do té magořiny s VM, kde možnost autonomie je vyšší a zároveň stále existuje i varianta, že kdo bude chtít, ať si to umístí na server třeba na Marsu. Jeho věc. Ale z pohledu mého vývoje, se okolnostmi kompatibilit s cloudy moc zabývat nechci, protože tím bych se jen vyčerpal.
Teď oceňuji, že se upřímně snažíte najít nějaké pozitivum, které by bylo průnikem snah s cloudy a snah s autonomní VM. To je super, jen nejsem teď schopen posoudit, kolik vaší energie a nadávek do toho spadne a jestli to za tu námahu fakt stojí... ? Možná to teď nemůžete odhadnout ani vy, protože se to musí nejdřív zjistit...
Napíšu teď spekulaci, která není zadáním, jen brainstorm:
Možná že dokážete přiohnout trochu kódu aby to chodilo, což by v rámci našeho deploymentu VM mohlo usnadnit sysadminovi konfiguraci vlastností Sahany. Ale bude to mít své hranice právě proto, že jde o řešení VM, nikoliv o řešení pro univerzální deployování na kdejaké cloudy. OK.
Moje znalost je bohužel omezená, nemám takové zkušenosti jako vy, takže nevím přesně, kde jsou limity naší instance, které by na cloudu nebyly omezené.
Spíš přemýšlím z tohoto úhlu: Jaká je přidaná hodnota pro uživatele za těch několik GB navíc? Pokud to na VM uděláme podle návrhu F+D, vytvoří to v důsledku více dotazů a potřeb po naší sys-asistenci, nebo méně? (vlastně bych stál o to, aby méně)
Neocenil by koncový uživatel spíš funkčnost, která by ještě více akcentovala unikátnost našeho autonomního řešení? Co by to bylo? Nějaká další spotterova offline služba, která je možná prkotinou, ale když najednou přestane existovat, tak je problém?
Možná promyslet nějaké Nefunkční požadavky softwarové architektury a zaměřit se na jednu-dvě... To se nemusí týkat jen Sahany, ale hlavně našeho řešení, které se pak promítne na jakoukoliv aplikaci.
Možná se porozhlédnout co je u Sahany pouze ve fázi Blueprintu a zároveň není zadáním nějaké konkrétní user-case. (Blueprinty chápu jen jako vyhalucinované nápady co by se třeba dalo....) A věnovat se více jedné konkrétnější záležitosti. (?)
Teď máme na VM instanci Demo, která se ukázala jako referenční sandbox pro naše pokusy. Otázkou je, zda v nějaké veřejné fázi je tento sandbox praktický, nebo zda se s těmi deployovacími funkcemi nestane nadbytečný. (ve smyslu, že i průměrně zdatný správce by si měl umět vyrobit svůj sandbox kdekoliv, kdyby o to stál)
Nebylo by nakonec vhodnější, aby sandbox na ostré VM byl identickou kopií instance Spotter? Tedy za předpokladu, že instance Spotter bude rozumně chodící bez těch nejkřiklavějších bugů.
Asi dílčí závěr:
Pro mne je fascinující kam až se dá průzkumem temných zákoutí SW dostat... jen bychom oba měli mít tu záklopku, abychom se udrželi v mezích realizace. V tom byste mi měl pomoci právě tím, že na základě průzkumu řeknete "A tady už dost" protože každý další krok je už masochismus, za který nikdo z nás nemůže být odpovědný... Protože zvěrstva páchá někdo jiný a těžko to ovlivníme.
Nejsme ve při. Na cloud kašlu, chci z toho vytřískat maximum pro lokální administraci. Bohužel ale budu vždycky limitován tím, že někdo to rozhraní vymýšlel primárně pro cloudy, takže se může stát, že tam budou nějaké čudliky nebo funkce, které u nás vědomě nebudou fungovat.
Ano, to je přesně to, čeho bych teď rád zkusil docílit. Jakmile se mi podaří donutit to v našem prostředí v rámci té jedné self-contained instance vypínat a zapínat moduly a upravovat nastavení, nalepím si hvězdičku a jdu od toho.
Na to v tuhle chvíli nemám odpověď. Myslím, že konkrétně tohle by se nijak zásadně do počtu dotazů a problémů promítnout nemělo. Tím, že to uděláme podle návrhu F+D ztratíme kontrolu nad prostředím kontejneru. Teď máme něco minimalistického, víme poměrně přesně jaké komponenty tam jsou, jak jsou mezi sebou propojené a jak jsou náchylné na průsery a náročné na údržbu. Jinými slovy, máme prostředí postavené pro účel aplikace. F+B vycházejí z generické instalace, kde je to prostředí víceúčelové a tedy poskytuje i funkcionalitu, která nikdy nebude využita, ale je stále nutno ji vést v patrnosti a udržovat funkční...
...což tu velmi úzce souvisí s udržitelností, na kterou se ve Vašem projektu snažím maximálně zaměřovat, protože ta heterogenita technologií, se kterými pracujeme, je tak obrovská, že kdybychom měli následovat doporučované návody a postupy a přebírat hotové kontejnery od tvůrců těch aplikací, které na VM máme, tak narazíme na limity systémových prostředků už po paralelním spuštění čtvrté aplikace.
Před lety jsme se domlouvali na tom, že ve finále budou dvě identické instance, jedna produkční a jedna na rozbíjení. To Demo tam teď máme právě jako referenční instanci pro potřeby reportování bugů, protože s tím množstvím úprav, které jsou ve Spotter template nejsme jinak schopni jednoznačně a rychle určit, zda bug existuje v upstreamu nebo jsme si ho tam zanesli sami nějakým špatným nebo nepochopeným nastavením. Průměrně zdatný správce by měl být nějakým způsobem (minimálně tím zdokumentovaným) schopen rozběhat skoro všechny aplikace, ne jen Sahanu, takže ano, až se dostaneme do nějaké méně experimentální a více stabilní fáze, default template budeme používat jen interně. Ty deployovací funkce na tohle nemají vliv. Té konfigurace je tam takové množství, že se nějaký vyčerpávající "uplácej si Sahanu" wizard udělat nedá, protože by měl asi tak 1500 čudliků. Té volitelné konfigurace bude zhruba tolik, kolik jí je teď, jinak dopadneme stejně jako F&B a budou za námi chodit lidi s tím, že když zapnou X, nastaví Y a kliknou Z, tak jim to spadne a nebudeme schopní efektivně podporovat všechny kombinace nastavení.
jj, třeba až do psychiatrické léčebny. :P
ok... jasné. Tak uvidíme co vyzkoumáte.
Funguje to. :)
Mergnu testovací větev a issue můžeme zavřít. Nakonec jsem asi rád, že jsem se do toho pustil, protože jsem v průběhu objevil ještě jednu věc, která je dost skrytá a v budoucnu by mohla vyskočit a kousnout nás do zadku. Sahana totiž vyžaduje starší verzi Web2py, které ale zas není kompatibilní s pythonem 3.8 a některými dalšími komponentami. I přesto, že jsem na tohle téma již posílal PR s patchem, který byl přijat, úplně jsem minul, že tam má Fran ještě jiný patch pro plánovač úloh. Na tom mé včerejší pokusy selhávaly, ale dneska už mi fo frčí.
Tento týden hodlám už konečně dokumentovat, takže kdyby se zdálo, že jsem zas umřel, tak tomu tak není. Pouze někde v ústraní zuřivě datluji epos o všem, co jsem za posledního půl roku dělal.
closed via commit
b1ff00e36bmentioned in issue Spotter-Cluster#68