Integráció - röviden

Minden integrációs projectnél végül oda jut a párbeszéd, hogy az integráló fél/kliens felteszi a kérdést: Hogyan oldjuk meg azokat a problémákat, amelyek az én rendszeremben jelentkeznek és a te rendszeredből jönnek?
Erre ez az általános válasz a szolgáltatók részéről: Azok a problémák, amik a te rendszeredben jelentkeznek, azok a tieid.

Cluster - magánvélemény + ötlet

Azok a clusterezési technológiák és szoftverek, amik uniform szervereket várnak el futtatókörnyezetként, komoly hátrányban vannak azokkal szemben, amelyek képesek a hardware különbségeit (pl memória méret, elérési sebesség, sustainable és random IO, CPU-k száma és sebessége, hálózat, satöbbi) kezelni. Ugyanis az ügyfelek nem szeretnék évekkel vagy akár csak hónapokkal előre megvenni a hardware kapacítást. Pl egyes projectek esetében nem nagyon lehet kitalálni, hogy mekkora kapacításra van szükség. Meg hát nem is tudják, kapnak egy adott összeget egy üzleti évre és legközelebb majd a következő üzleti évben lehet hardware-t vásárolni. Akkor már más lesz a kinálat. Még ha mindig a listán is van a régi szerver tipus, akkor is valószinűleg más hardware fogja akkor megérni, más az akciós, satöbbi.

Például nekem a cassandra, amikor teszteltem nagyon makacsul ragaszkodott ahhoz, hogy egyenlően ossza fel a keyspace-t minden alkalommal, amikor új node-t csatlakoztatok.

Ezt gondoltam csak azért írom ide fel, mert nem olvastam egy könyvben sem eddig, ez amolyan magánvélemény.

Ötlet: Csak példaként egy private cloud-ba érdekes lehetne olyan logikát írni, ami felstartol mégegy mongodb szervert, ha a cluster átlagos terhelése X főlé nő, lekapcsol egyet, ha Y alá csökken, megtart tartalékba Z-t mindig. Nyilván nem csinál ilyet az oVirt, de más rendszerek biztosan igen. Bocsi, hogy megint oVirt lett belőle...
Ez persze a fizikai vasakon futó rendszereken nem segít, nem "silver bullet", de egy egyszerű megoldás lenne a probléma java részére.

oVirt or oVirt

Néhány további a múltkori dolgokhoz az oVirt-tel kapcsolatban, most nem annyira felhasználói oldalról, kicsit inkáb belülről.

Poll

Az oVirt hogy bármilyen információt beszerezzen a futó VM-ekről, poll-ozgatja a host-gépeken futó agentet (ennek VDSM a neve). Az agenttel csak két problémám van:

• Új szoftvert írni XML-RPC-re? Ez komoly? Akkor már miért nem CORBA? :)
• Néha úgy tünik az alatta levő libvirt-tel hamarabb szótértenék. Például oda lehet callback-eket is regisztrálni.

A pollozás mellett amit nem szeretek, az az, hogy a leszedett információt egyszerűen belecsapjuk az adatbázisba és nem csinálunk semmit, várjuk hogy valaki megkérdezze. Ezzel kapcsolatban borzasztóan kiváncsi vagyok, hogy vajon miért. Egy tranzakciós adattárolóban tartunk valamit, ami tökre nem tranzakciós. Minden alkalommal amikor kellene tudni, egy Host-on mennyi szabad memória van, az adatbázisból kérdezzük le.
Szóval szerintem:

• A host éppen aktuális állapotát nem adatbázisban kellene tartani, hanem a memóriában vagy elosztott cache-ben. Az adatbázis nem cache!
• A hostot lehet hogy kell poll-ozni időnként, hogy életben van-e még, de sokkal hatékonyabb lenne ha streamelné az adatokat, ha már van agent
• A streamelt eseményeket akár JMS sorban priorítási sorrendben lehetne feldolgozni, tetszőleges szálon. Ezeknek az eseményeknek kellene elindítania a döntési folyamatokat. (pl hogy a host túlterhelt, valamelyik Vm-et át kell migrálni máshova)

Kereső

A kereső egy tipikus szent tehén, senki sem mer hozzányúlni. Nagyjából úgy van most, ahogy átportolták .net-ből. A másik nehézség, hogy jó részét megosztv használja a GWT frontend és a backend, így aztán tényleg nehéz is hozzányúlni, de azért egyszerűsítgetni simán lehet benne mert nagyon cifrán redundáns.
A kereső egy apró baja az, hogy SQL lekérdezéseket gyárt, nem holmi lucene vagy hasonló okoskodás. Az SQL se rossz persze, de a postgres-nek rettenetes bajai vannak a generált lekérdezéseivel. Degeneráltak a lekérdezései. Szóval a kereső is jól tökönrúgja az adatbázist, de a kód ami a lekérdezést generálja tényleg nehéz eset, elösször kicsit egyszerűsíteni kellene rajta, de azt nem lehet, mert így "működik".

Kompenzációs tranzakciók

Hallottál már olyanról, hogy kompenzációs tranzakciók? Én csak véletlenül futottam bele régebben, de soha nem láttam alkalmazva. Ez a megoldás azért lett bevezetve, mert a kommunikáció a hostokkal lassú, közben lockolunk rekordokat és a postgresql-nek nincs read uncommited tranzakció izolációs szintje. Mondjuk még mielött tiltakozni kezdenél, hogy azért van más épkézláb megoldás: persze van. De mindenesetre valahogy úgy jött ki, hogy egy bizonyos táblába tol az oVirt mindent, és lezárja az adatbázis tranzakciót, egy tranzakciók feletti tranzakciót csinál. Aztán ha N adatbázis tranzakció után belefut egy hibába, akkor megpróbálja visszacsinálni ezek alapján a rekordok alapján.

1. Ez kézzel hímzett megoldás, rettenetesen sok kódsor szolgálja
2. Nem biztos hogy sikerül a kompenzációs tranzakció, és akkor megakadunk ott, ahova nem akartunk eljutni
3. Ha kompenzáció nem sikerül az engine indításakor, akkor az engine el se indul. A felhasználó meg néz hogy mivan.
4. Bár a tranzakciókat igazán egyidejű hozzáférésre találták ki, a kompenzációs tranzakcióknál teljesen para az egyidejű hozzáférés.

Nem lenne nehéz megoldani, hogy a Host műveleteket az oVirt asszinkron kezelje. Küldözgessen JMS üzeneteket, vagy akármi. Én egyébként szivesebben barátkoznék a gonosz MySQL-lel is akár, mint hogy egy tranzakciós rendszer tetejébe workaroundként mégegy tranzakciós rendszert húzzak.

Adatbázis

Á igen, rendesen tökönrúgjuk az adatbázist a HOST/VM státusz adatok örökös írogatásával, a hülye kereső lekérdezésekkel, de ez nem fáj nagyon, amíg nincsen sok VM-ed. (Mondjuk miért használnál olyasmit, mint az oVirt, ha nincs sok VM-ed?)
Viszont helyenként rendesen tökön rúgjuk szegény PostgreSQL-t olyanokkal is, hogy egy ciklusban kérdezünk le valamit belőle, ahelyett, hogy egy értelmes lekérdezést írnánk. Ez nekem az egyik legfájdalmasabb dolog, mert ez direkt van így és nem értem miért kell hogy így legyen. Nemrég kellett egy bugot kijavítsak és első nekifutásra kicsit okosítottam a lekérdezésen, de ezt nem fogadta el a reviewer (aki szerintem beletette a bugot). Az elfogadott megoldásban kénytelen voltam iterációban kérdezgetni az adatbázisból. Ez a rendszered növekedésével exponenciális terhelésnövekedéshez vezet. Baromi zavaró, amikor ilyeneket csináltatnak velem.

"Mindenki más faszával szereti verni a csalánt"
- ZTutto

"oVirt or no virt"

Megint melóval kapcsolatos pár gondolatot szeretnék megosztani magammal, nyugodtan hagyjátok figyelmen kívül. Szóval pár dolog, ami az oVirt-ben nagyon szeretném ha fejlődne, de sajna nem fejlődik akármennyit is túlórázok. Ugyanis teljesen mással vagyok elfoglalva, pl újabban python-ban programozok, legalábbis imitálom, a kedvem viszont rohamosan fogy.

VM ütemező

Ha van egy adatközpontod -és ne valami CERN-Google-fakebook mega-vastelepre kell gondolni, hanem akár a sufniba bevágott 6-8 leselejtezett asztali gépből összefabrikált teszt clusterre- amin elfut 20-30 különböző virtuális gép. Szóval már a 20-30 gépnek is kimérni hogy melyik gépen fusson, hogy ne pont egyszerre kezdjék agyonhajtani az egyik vincsit, a hálózatot, satöbbi... ez túl sok meló. Az oVirtben ezeket a dolgokat, hogy CPU-pinning, hosthoz kötés, ezek enterprise virtualizáció néven oké (gondolom az enterprise az ökörséget jelenti). De akár már néhány VM-en is kikisérletezgetni az optimális konfigot, nekem se lenne hozzá kedvem. Ez had legyen a droidok sportja.

Az oVirt VM-ütemezője viszont a memória pillanatnyi kihasználtságán kívül kb mindent figyelmen kívül hagy. Egy ütemezőnek figyelembe kellene vennie:

• a memóriát természetesen
• CPU kihasználtság
• merevlemez használat
• hálózat használat
• ÉS nem csak az éppen aktuálisat, hanem az azon a gépen futó VM-ek tipikus terhelését. Például van éjfélkor elindul pár job az egyik VM-en ami generál némi aktivítást, vajon odafér-e mellé még egy másik gép által generált aktivítás is?

Persze nem mondom, király, hogy ki tudod jelölni,hogy melyik gépen fusson a szervered. De mennyivel jobb, ha nem kell vele foglalkoznod. Én már akkor a lehetőségről is lemondanék. Miért akarnék én magam migrálgatni VM-eket egyik dobozról a másikra?

Power save

A másik dolog, amivel nehezen tudok megbarátkozni, hogy az oVirt soha nem kapcsolja ki a hostokat. Ott van minden power management-tel kapcsolatos info, és nem. A használatlan hostokat milyen király lenne egyszerűen kikapcsolni. Kevesebb zaj, nyáron az se rossz ha kevesebbet fűtünk, barátibb villanyszámla, meg addig a csapágy se kopik :-)

Ja és persze kiragaszthatod magadra, hogy zöld vagy mint egy mozgalom és egylet.

Majd ha kell a host, akkor bekapcsolhatjuk automatikusan.

Valamint ha egyszer tényleg kikapcsolná a hostokat az oVirt, akkor nagyon királynak tartanám ha nem csak a szokásos IPMI, DRAC, stb interfaceket használnánk, hanem a primitív wake-on-lant is akár. Wake-on-lan a világon mindenben van, amiben van ethernet csatlakozó. Sajnos amennyivel többe kerül egy IPMI-os interface-szel szállított echte Dell szerver, na annyit nem takarítassz meg a villanyszámlán egyhamar.

VM pool

A VM pool szerintem félbehagyott feature. Pedig király lenne. A VM pool jelenleg ezt csinálja: egy template-ből csinál neked annyi VM-et amennyit akarsz, és nyilvántartja, hogy azok a pool-ba tartoznak. A pool létrejöttekor illetve módosításakor létrehozza a konkrét VM-eket. 

• Olyan API hivás sincs, hogy "adjál egy VM-et abból a pool-ból"
• A stabil méret helyett szerintem a maximum és minimum érdkesebb lenne.
• Olyanok is inkább érdekelnének, hogy az oVirt automatikusan elindítson a pool-ból új VM-eket bizonyos kritériumok esetében. Pl ha minden gép legalább 50 % CPU terhelést kap, stb.
• Ha azt mondom pool, akkor olyan dolgok halmazára gondolsz, amik közül mindegy, hogy melyiket kapod meg, mind ugyanazt tudja. Szóval szerintem egy olyan pool esetleg hasznosabb lenne, ami nem hozza előre létre a VM-eket, hanem a template-ből bármikor csinálhat egy újat. Mi a fenének foglalják a helyet addig?

VM Set

Ilyesmi nincs az oVirt-ben, szóval ez egy feature request lenne. Nagyon gyakran van olyan, hogy egy project fejlesztői környezetéhez létrehozol hálózatot, X darab virtuális gépet, amik különböző komponenseket futtatnak a rendszerből. Pl valami load ballancer, X db servlet container vagy app szerver, egy adatbázis szerver, vagy esetleg egy fél tucat NoSQL. Szóval azért lenne őket értelme egyben tartani, mert olyan dolgokat lehetne csinálni velük, mint klónozás, hogy a dev környezet szenvedést ne kelljen megismételni N alkalommal. Vagy akár együtt az egészet learchiválnád és lekapcsolnád, amikor a project végetér. Abban is segítene, hogy a set gépei pl elsősorban egymással kommunikálnak, szóval érdemes lehet őket ennek megfelelően pakolni hostokra.

... és így tovább, még van jónéhány ötletem, csak most mingyá hajnalodik.

Eclipse democamp pénteken

Aki még esetleg nem tudna róla: péntek este budapesti eclipse democamp.

Leginkáb az XTend nyelv érdekel az előadások közül, annak ellenére hogy szerintem nem a nyelv a probléma a java környékén.

Gyárlátogatás: KÓD_KONVENCIÓ

Hali, ismét gyárlátogatáson vagyunk, zsebrevágott kézzel körbevizslatunk az üzemben, megnézzük mit csinálnak a szakik. Gondoltam ma kicsit mesélnék arról, hogy miket láttam kód konvenciók háza-táján, milyen viták zajlanak, hol és mi fáj. Ne várjatok nagyon objektív megközelítést, ez az egész személyes élmények alapján.

A legtöbb kód konvenció csak a fejlesztők életét könnyíti vagy nehezíti meg. A forráskód fordítása után a tárgykódban már nincsenek se szóközök, se kommentek, se tabok, C nyelvben még a változód neve is eltűnik, java-ban is inkáb csak a mezőknek van jelentősége. Szóval ilyen szempontból a dolog kevés értéket jelent az ügyfélnek, aki végülis fizetni fog (reméljük) a termékért.

Nevek

C++-ból és hasonló területekről érkező szoftverfejlesztőktól gyakran láttam hungarian notation-hoz hasonló neveket. pl a mezőket sokan kedték aláhúzással, mint _name, vagy my prefixszel, pl myName. Régebben sokat láttam szigorúbb hungarian notationt java programozóktól is, pl volt olyan munkahelyem, ahol meg a paramétereket is 'a'-val (mint argumentum) kellet kezdeni.

A legviccesebbnek azt a konvenciót találtam, ahol az entitás osztályokat és azoknak a mezőit magyarul kellett elnevezni. Szerencsére ékezeteket nem akartak, de sikerült amolyan kicsi bábelt létrehozni a forráskódban, ugyanis a java többi része és library-k továbbra is angolul vannak.

if(fejleszto.isHulye()) ...

Egyes konvenciókat a java nyelvben én is teljesen figyelmen kívül hagyok, az egyik ezek közül amit a legtöbbször vágnak a fejemhez, a konstansok NAGY_BETŰS elnevezése, helyette a konstansokat is sima mezei camelCase írom. Akkor pár ok:

• A NAGY_BETŰS konvenció a C nyelvből érkezett a java nyelvbe. Ott a prepocesszor makrókat ajánlott nagybetűsen írni, ugyanis komoly gubancok származhatnak belőle ha elfelejted. Java-ban udvariasan szól az eclipse vagy amit hajtassz, hogy "komám, az final". Nem mondod komolyan, hogy vim-ben írsz java kódot? Ja emacs, persze, de kis buta vagyok :-D
• Enum-okat: Igen, ami az enumban van az effektive public static final, de miért kellene mindent nagy betővel írnunk benne? Mint egy állítólagos nigériai tábornok lányának a takarítónöjének a majma egy e-mailben.

Tab vs space

"te tab-bal tabulálsz?
bnzi-e vagy" - beteg-patkány-ember

A másik ilyen kérdés a space vs tab hitvita. Nem szeretnék senkit se rábeszélni arra, hogy áttérjen a másikra, de a harcos space-hívőknek: Ha a space a tabulálásra van akkor a tab vajon mire van?

Ez a tabulálás dolog viszont leginkáb a python fejlesztők között okoz viszályokat, pár hét python buherálás után én így kategorizálom be a python fejlesztőket:

• tab-os pythonos
• 4-spaces pythonos
• 4-től eltérő mennyiségű space-szel tabuláló pythonos

És mind meg van győződve róla, hogy ő vágja a témát és a többi falhozvert lófasz. A projectemen többségében 4-spaces pythonosok vannak, szerintük a pythonnak nagyon fontos, hogy pont 4 legyen. Ennek ellenére a kódban tucat helyen el van cseszve és csak 3 space. Sajnos kb azonnal elfelejtettem az indoklást, az összes python scriptem futott a tabokkal.

Sorhossz

A sorok hossza ami a másik dolog, amivel teljesen értelmetlenül és eredménytelenül lehet vitatkozni egy pár órát. Kezdetekben mindenkinek volt a szép karakteres képernyője, ami képes volt 80x25 karakter megjelenítésére, innen származott az a tradíció, hogy legyünk szivesek 80 karakternél többet ne pakolni egy sorba. Hát azóta eltellt egy kis idő, közben a képernyők közül a 23 colos lett a standard. Amennyiben nem a mobil telefonodon fejlesztessz. A sorok szélessége viszont sok projectben megmaradt 80 karakter.

Kicsit ez a dolog kapcsolódik a space vs tab vitához, mert a tab méretét lehet változtatni a szerkesztőben.

Kommentek

Talán ezzel volt a legkevesebb gubanc, mert áltaáában a fejlesztők beérik kevés dokmentációval. Egy ellenpéldával találkoztam, konkrétan az oVirt projecten dobták vissza az egyik patch-emet egy csillag miatt. Ugyanis egy kicsit bonyolultabb kóddarabhoz odaírtam, hogy mi a fészkes fenét csinál ez az egész, és a többsoros /* */ kommentet használtam. Erre valakinek az volt a kifogása, hogy "mi" csak a /** */ -t használjuk.

Akkor kapd be a patch-em :-)

Egy kis saját: final paraméterek

Á igen, gondoltam a végére csemegének megint egy saját paranoiámat dobnám be. Legalább tudok róla, hogy van :-) sőt már egyszer meg is gyóntam. Szóval amerre járok, hajlamos vagyok főleg a hosszabb metódusok paramétereit átírni final-ra. Ennek funkcionálisan a világon semmilyen következménye nincs: amennyiben lefordul, működni is fog. Azért alakult ki nálam ez a szokás, mert a parameter-reassignment-et teljesen olvashatatlannak tartom.

De én legalább senkivel nem kezdek el cseszekedni, ha nem finalként definiálja a paramétereket a patcheiben :-)

Policy Police

Pár eszközt említenék meg a kód konvenciók betartatásához illetve figyeléséhez:

• nagyon szimpatikus a sonar. Azt is meg lehet oldani vele, hogy elhasaljon a build, ha súlyosabb hibát talál, de ilyen beállítással még nem találkoztam. A sonarral kapcsolatban azt tartom szomorúnak, hogy nagyon kevesen használják ténylegesen, pedig átalában egy csomó dologra hívja fel a figyelmedet, szerintem a használatával tényleg tanulhatsz pár érdekes dolgot, legalábbis én tanultam tőle.
  A legfontosabb, hogy időben láthatod a változást. Szerintem az egésznek nagyon kevés értelme van, ha nem a változást figyeled.
• nagyon idegesítőnek találtam a maven-checkstyle plugint, ami az ovirtben nem csak pazarolja az időmet, de olyan marhaságokon képes eltörni a buildet, mint trailing spaces. Amikor éppen egy kritikus hibát próbálsz javítani el tudod képzelni mennyire örülsz egy ilyennek.

Amúgy nekem végülis 8, mondhatnám. Magyar jelöléses 80 karakteres sorhosszú, dokumentálatlan és akár egysorba írt kódot kapunk és nem ettől lesz az eredmény egy stack trace.

A kód konvenciókban engem az zavart mindenhol, a C/C++-os, Perl-es Python és PL/SQL-es projectekben egyaránt, hogy a kód konvenció személyenként változott. Azaz ha bedobod review-ra a patch-et, akkor attól függően lesz lefikázva vagy elfogadva, hogy ki nézi meg. Kb mint egy vizsgán, hogy melyik tanárnál vizsgázol.

Projectek illetve cégek különböző csoportai között egyre nagyobb véleménykülönbségeket láttam.

Ezzel együt lehet élni persze, a probléma akkor következik, amikor az egyik csoport megpróbálja rákényszeríteni a konvencióit a másik csoportra, illetve meg akar határozni egy globálisabb (pl céges) kódkonvenciót. 

Na, ez az amiből egyetlen egy sikeres próbálkozást nem láttam, de nagyon hosszú és anyázásig elmenő vitát jópárat.

"Persze, hogy benne van a céges policy-ban. Most írtam bele."

Én azt hiszem az lenne egy egyensúly közeli állapot, ha egy-egy projecten együtt dolgozó emberek a nem funkcionális elvárásaikat megbeszélnék nem egy bizottsági üllés keretében hanem inkrementálisan, ahogy jön. Azt is jobbnak hiszem, ha ezeket a szabályokat nem próbálják meg keményen bármi áron betartani. Ha funkconálisan teljesen jó és nem halom ganaj a kinézete, had jöjjön, aztán lesz időnk szépítgetni. 

Nyugdíj után bármire :-)

Ezt én sem tarom univerzálisan bevethető dolognak, a demokrácia nem mindenkivel működőképes, egyre több emberrel pedig egyre kevésbé.

Small is beautiful

Lassanként minden a felhőben szalad, mert az (többnyire, eleinte, állítólag, stb) olcsóbb, és persze a felhőben fogyasztás alapján számláznak. Azaz megkapod havonta a memória fogyasztásodról a számlát minden hónapban újra és újra. Nem csak akkor, amikor leslattyogsz a boltba megvenni a RAM-ot a gépbe.

Szóval vajon ez az újra és újra megjelenő kiadás elegendő motiváció-e arra, hogy kisebb memóriaigényű szoftvereket fejlesszünk és futtassunk?

Például a jetty elfut 256 MB memórián. Még egy DB-nek is akad hely, azaz a legkisebb VM-en is simán elszalad. Egy JBoss-t vagy Glassfish-t nem inditasz el azért 1 GB alatti memórián. Illetve ha megveszed minden hónapban a memóriát, nem-e inkáb valami hasznosra használnád? Még az I/O cache is sokkal hasznosabb, mint egy tucat teljesen kihasználatlan feature a kedvenc JEE szerveredben.