No kerub-agent

A legtöbb IaaS egy agent nevű szoftverre épít, ami minden host-on fut. Ez egyrészt egy olyan szoftver, ami a kommunikációt bonyolítja a controller és a host között, másrészt egy absztrakciós réteg is.
Az ovirt-ben ez egy VDSM nevű python script, ami XML-eket kap a kontrollertől és azt lefordítja másféle XML-be, konkrétan a libvirt XML formátumába, másrészt pedig néha operációs rendszer parancsokra, szóval kicsit többet csinál mint egy XSLT processzor :)
A cloudstack-nek egy java agentje van. Elsőre kicsit soknak tünhet akár fél gigát is beáldozni a host memóriájából egy ilyen, viszonylag erőforrásigényes processznek, de tipikusan a cloudstack felhasználók TB-ben mérik a host memóriát és fél giga nem kategória. A java-t inkáb azért nem tartom szuperfrankó választásnak agenthez, mert brutálisan béna az operációs rendszerekkel az integrációja, például a processz kezelés, meg persze mindenkinek vannak ellenérzései a JNI-vel szemben. JNI pedig van, persze hogy van...
Viszont itt nyilván előny, hogy a java fejlesztő, aki a kontrollert buherálja, az az agentet is simán buherálhatja minden további tanulmányok nélkül.

Mindkettő http protokolt használ: kapcsolódunk, kezetrázunk, bemutatkozunk, valami teljesen minimális dolgot közlök veled aztán elbúcsúzunk és fél másodperc múlva újrakezdjük. Az oVirt még emellett egy döbbenetes dolgot is csinál a tranzakciókkal, ami a MS-SQL-ből PostgreSQL-re való áttérés (és talán egy súlyos félreértés) eredménye.


Amikor azon gondolkodtam, hogy hogyan tudnék jó agentet a kerubhoz, elösször is inkáb azon gondolkodtam hogyan lehetne megúszni az egészet, mert nincs rá időm. Másodszor pedig szerettem volna megszabadulni a kommunikációs overhead-tól, pl xml parsing.

Végülis az, hogy nincs agent, azt nevezhetjük félrevezető marketing-baromságnak, mert valamilyen szoftvernek futnia kell, amivel kommunikálunk. Ennyi lett: OpenSSH, az OpenBSD klasszikus SSH szervere, ami fut linuxon, windowson (cygwin), mindenféle BSD-n és solarison, ráadásul többnyire része egy szerver alaptelepítésnek.


Az absztrakciós réteg... egy része ott van a kontrollerben, mert annak tudnia kell, hogy milyen operációs rendszerhez beszél, az absztrakciók nagy része viszont elment. Eleinte csináltam abstrakciót a hypervisor-elé, de később találtam jobb megoldást és mostanában lassan eltávolítom ezeket a kerub-ból.

Ez most hosszú lett, mert vasárnap van, legyen legközelebb például az, hogy mit csinál a planner és miért nem kellenek az absztrakciók.

Gyárlátogatás: az adatbázis

Rég voltunk gyárlátogatáson, gondoltam ismét belerúgok a műfajba, ezúttal az adatbázisok és használatuk területéről írok pár személyes élményemet. Mint mindig, nem arról lesz szó, hogy hogyan kellene, hanem arról, hogy mit csinálnak a szakik a gyárban.

Fellegvár

97 Dolog, amit minden Architektnek tudnia köllene (és mégse tudják), 23. bejegyzés: Legyen erőd az adatbázisod!
Ezt a sírjára vésném azoknak, akik nem tartják be :-) Az adatbázist nem bíznám az izgága programozókra. A DBA egy külön szakma, más mentalítást és más egyéniséget igényel, mint a szoftverfejlesztés. A legjobb tapasztalatom adatbázisokkal annál a munkahelyemnél volt, ahol külön DBA csapat volt. Ezek a csákók vágták az adatbázis minden paraméterét és rendesen lecsesztek mindenkit, akinek az alkalmazása nagy mennyiségű hülyeséget csinált. Persze nem klassz, amikor az embert lecseszik, de néha hasznos.

Az profi üzemeltető csapatból következik még egy dolog: nem akarnak sokféle adatbázis szervert üzemeltetni. Ha elöjössz azzal, hogy neked KakukkSQL kellene, mert a hétvégén kipróbáltad és most az a kedvenced, őseid legkevésbé sem magasztaló kontextusban kerülnek megemlegetésre.
Többnyire 1 cég 1 adatbázishoz ragaszkodik, de legalább abból az egyből elég jó szolgáltatást kapsz.

Ha így nézed a dolgot, marha fontos, hogy az alkalmazásod több adatbázissal is jól szaladjon, amennyiben nem csak 1 ügyfélnek akarod eladni, illetve nagy ügyfeleket is szeretnél célozgatni, akik nem akarnak holmi közös felhőben lakni. Oké, talán ez egyre kevésbé tényező...

Szamócából fellegvár

Egy régi főnökömtől származik a mondás, ami mindig eszembe jut, amikor egy adatbázist rendesen tökön rúg egy alkalmazás:
"Ne aggódj, az Oracle végtelenül skálázható." Én meg kérdeztem mint egy hülyegyerek hogy "Tééélleg? És mennyiért?"

Ezt általában el lehet mondani, hogy kevés elképzelése volt az embereknek eleinte arról, hogy mennyit bír egy adatbázis szerver és a hardver mérettel ez hogyan változik, illetve az adatbázis mérete hogyan befolyásolja a teljesítményt. A fenti dologgal ma már nem hiszem, hogy bárki előjönne, de nekem úgy tűnik továbbra is kevesen tudnak arról bármit is, hogy az adatbázisuk miből mennyit bír. Konkrétan számszerűen, mert az akármennyi az nyilván baromság.

Indexelés és optimizálás

Sajnos nagyon kevés java fejlesztő néz bele akármikor is, hogy a lekérdezései mit is csinálnak konkrétan, pedig minden adatbázisban van valami query debugger funkció, többnyire explain-nek hívják. Ez azért lenne fontos, mert az adatbázis a munka nagy részét elvégzi, amit a hétköznapi ügyviteli rendszereink csinálnak, az valójában csak minimális feldolgozás rajta. Ha kicsit jobban bánunk az adatbázissal, az valószinűleg kategóriákkal többet fog javítani az alkalmazás teljesítményén, mintha felűberelnél a JLophas AS legeslegújabb verziójára, vagy mint ha a teljes alkalmazásban levadásznád a hülye "ez" += "az" konkatenációkat, a temp objektumokat, satöbbi. Sajnos ez van.

 

JPA&Co

Sajnos a perzisztencia frameworkok csak tovább növelik ezt a távolságot a fejlesztők és az adatbázis között. Annyi azért viszont biztos, hogy a JPA implementációk nem generálnak olyan idióta lekérdezéseket, mint egyes alkalmazások JPA nélkül. Most inkáb kihagynám a példát :-D de biztosan találsz a házad táján.

Kétségtelenül nagy előnye a portolhatósága és a gyors fejlesztés, de néhány dolgot néha optimalizálni kell, különben agyonveri az alkalmazásodat. Erre javasolnék egy patternt: csinálj egy általános JPA DAO-t, ebből származtass le szükség esetén DB-specifikus implementációkat és bíráld felül (gyakorlom a magyar nyelvet, az override-ra gondoltam) azokat a lekérdezéseket futtató metódusokat, amiket optimalizálni akarsz. A DAO-kat egy factory-val gyártsd le, ami az adatbázis típusától függően ad vissza egy implementációt.

Mégegy dolog: az automatikus séma generálás nem jó, mert az említett "erődítmény" tétellel ellentétes. Prototypinghoz természetesen kiválló, de az adatbázis adminisztrátorod megöl érte. Talán érdemes írni egy listát, hogy mit kell tenni amikor már komolyan gondolod az alkalmazás fejlesztését, és mondjuk így kezdeni: automatikus séma generálás kikapcs.

 

Cache vagy MQ

Egy gyakori probléma, amivel találkoztam, hogy az adatbázist cache-ként vagy üzenetek küldésére használták. Ennek az oka valahol az egyéb infrastruktúra hiánya és az ismeretek hiánya között volt általában, kicsit mindkettő.
Talán ida tartozik, hogy a Quartz is használ relációs adatbázist Job storeként és elosztott lockoláshoz. Határeset...
Mondjuk a Quartz-ról ma hajlamos vagyok azt gondolni, hogy antipatternek gyüjteménye.

 

Tárolt eljárások

Ez egy rettenetesen vitás téma az adatbázis adminisztátorok és a fejlesztők között. Több DBA-val találkoztam, akik megkövetelték vagy elvárták a tárolt eljárások használatát.
A java fronton ellenben a tárolt eljárásoknak nem igazán népszerűek. Illetve igazán nem népszerűek. Ennek több oka is lehet: elösször is egyetlen egy tárolt eljárás nyelv sem portolható. A java tárolt eljárások inkáb az előző évtized közepe tájám volt egy próbálkozás, csak a DB2 és az Oracle támogatta, PostgreSQL-re ketten írtunk rá támogatást, de őszintén egyikünk sem lett nagyon népszerű vele, évek óta leálltunk a fejlesztéssel.
Portolhatóság szempontjából a tárolt eljárás inkább akadály, mint segítség, a legtöbb persistence framework nem tud velük mit kezdeni.
A népszerűtlenség nagyobbik oka viszont nem a portolhatóság hiánya, hanem egyszerűen az, hogy a tárolt eljárásoknak az esetek nagy részében egyszerűen nincsen semmi előnyük, de nehezeben áttekinthetővé teszik a rendszert. Példának sajnos az oVirt-et fel tudom hozni, a legegyszerűbb lekérdezést is bele kell csomagolnunk egy tárolt eljárásba.

Igazából én egy csomó lehetőséget látnék tárolt eljárásoknak olyan téren, mint az interakciók számának csökkentése az adatbázis és az alkalmazás között. Pl insertOrUpdate, insertAndReturnId. Ilyesmi használatát nem emlékszem hogy láttam volna valakitől.

Tranzakciók

A tranzakciókkal is láttam pár buherát. Egyes rendszerek (pl ovirt is sajnos) egyenesen problémaként élik át a tranzakciók létét és bonyolult, bizonytalan kimenetű dolgokat csinál a kicselezésére.
A kedvenc trükk, amit láttam, mégis az volt, hogy az app egy bizonyos lekérdezésre nyitva hagyta a tranzakciót és a kapcsolatot, meg egy ResultSet-et is, és a következő http requestre tolta ki az eredményt html-be. Néha, amikor a második http request mégsem ütött be, akkor kicsit elakadtak a dolgok. Erre adta a rendszergazda azt a diagnózist, hogy "A program egyébként jó, de a tomcat egy rakás sz.., naponta újra kell indítani"
Ezek a trükközések elég hajmeresztőek, de nem ritkák.

A NoSQL forradalom

Nincs antipattern tapasztalatom a NoSQL adatbázisokkal, mert sajnos munkában még soha nem használtam őket, de alig várom. Talán oda jutott a dolog a tradícionális RDBMS modellel, hogy néhány dolgot, például a tranzakciókat (lásd fent) egyáltalán nem találunk hasznosnak egy olyan alkalmazásban, mint egy chat, alkalmazás logok, vagy szociális háló. Egy évtized kellett hozzá, hogy az internet ipar saját ötlettel áljon elő és elrugaszkodjon az inkáb a pénzintézetek igényeihez igazodott modelltől. Jelenleg annyi NoSQL adatbázis van, hogy nem tudom felsorolni őket és nem tudok mindegyikkel lépést tartani. Azt hiszem még évekbe fog telleni, amig letisztul a terep, pár kellemetlen élmény keletkezik elötte. Például a mongodb-ről hallottam pár forrásból, hogy végül felhagytak vele. Én még mindig hajtom, persze nem atomreaktort vezérlek vele. Egyébként nem hiszem hogy a mongo végül a kiesők között lenne, de pár másik ott lesz.

[szerintem nem] elszállt ötletek: a VM scheduler

Szóval arra gondoltam az óév pár utolsó napján felrázlak titeket pár ötletemmel, talán pár hasznos dolog is kisül belőle. Kicsit többre gondoltam eredetileg, mint amennyi összejött, de egy hétig otthon voltam, mászkáltam erre-arra.
A legutóbbi ötlet végén utaltam egy megintcsak meló-kategóriás ötletemre az oVirt-tel kapcsolatban: szeretném kicsit okosabbá fejleszteni az oVirt VM-schedulerét. Valamennyire megvan rá a jóváhagyás is és erről a témáról beszéltem idén Barcelonában a Linux confba beágyazott oVirt workshopon.

Mi az a VM-scheduler?

A scheduler az a dolog, ami a vason kiosztja a vason, hogy mi és hol fusson. Egy ilyen nyilván minden operációs rendszer kerneljében fut nagyon frekventáltan, hogy eldöntse hogy melyik processznek adjuk oda egy kicsi időre a CPU-t. Ezek az algoritmusok egészen bonyolultak is tudnak lenni (pl gondolj csak a NUMA architektúrára) ahhoz képest, hogy nagyon gyorsan kell futniuk, tudományos cikkeket írnak róluk, satöbbi-satöbbi. Szerencsére van rá az ember, mert én ezzel nagyon nem akarnék foglalkozni.
A VM scheduler egy kicsit más kategória:

• a feladata a virtuális gép számára egy fizikai szerver kijelölése
• plusz esetenként (kellemetlen esetenként) migrációk ütemezése
• ritkábban fut: minden alkalommal, amikor Vm indul, illetve ha egy szerver terhelése túl nagy
• több erőforrás áll rendelkezésre
• viszont a teljes szerverfarm teljesítménye nagyban függ a döntés minőségétől
• a cefet-nagy sebességgel szemben én többre értékelném a skálázhatóságot és az értelmes eredményeket, persze a sebesség is szép

Mit tud ma az oVirt schedulere:  erről már írtam egy nagyon bosszús pillanatban, ugyanakkor amit írtam fentartom: a scheduler lassú, a kód zavaros és a döntései néha egészen hülyék.

Szóval mi történik ezen a fronton: egy ideje semmi, mert más (tökunalmas marhaság) feladaton kellett dolgoznom, de egyébként elkezdtem írni egy specifikációt és egy patch-et, ami a drools plannert használja fel optimalizációra. Ebből osztanék meg veletek pár alapötletet:

• A drools planner úgy dolgozik, hogy egy bizonyos felálláshoz kiszámítja a pontokat, aztán keresőalgoritmussal nekilát jobb felállást keresni. Szóval a pontszámítás a lényeges pont. A pontszámításra azt találtam ki, hogy külön kiszámítjuk minden esetleges tervhez:
• a szituáció költségeit: ide tartozik az, hogy mennyire fáj a jelenlegi helyzet, olyanok mint CPU-túlallokáció egy kis bünti, memória túlallokáció egy kicsit nagyobb bünti. A tényleges CPU és memória használat is ide kerül, csak azokra sokkal nagyobb böntit szabunk ki.
• az esetleges migráció költségeit: a migrációnak kell legyen egy alapköltsége, hogy ne dobáljuk idiótán pillanatnyi ötletek alapján a virtuális gépeket egyik gépről a másikra. Ezen kívül egyes erőforrásokat is megadóztatunk a migráció során, például a lefoglalt memóriát teljesen át kell másolni a másik gépre, ami idő persze.
  Itt üthetnek be a hard constraint-ek, pl a cél gépnek egyáltalán nincs annyi memóriája, mint amennyire a VM-nek minimum szüksége van.
• a migráció előnyeit (kompenzáció): miután megadóztattuk rendesen az aktuális helyzetet, és mindent ami esetleg kivezet innen, kell egy dolog, amit a kereső megtalálhat esetleg jobb megoldásként. Itt ilyen dolgokat lehet fdelsorolni, mint pl a CPU-overallocation a migráció után kisebb lesz. Illetve ha nagyobb akkor még arra is büntetést teszünk ki a kompenzáció helyett.

•  A schedulernek bizonyos időn belül válaszolnia kell. Egy cluster áttervezésnél én el tudnék viselni akár 4-5 másodpercet is, de kifejezetten értékelném, ha folyamatosan és inkrementálisan tervezne. A VM startnál kicsit izgágább a kedves felhasználó, általában szeretnék, ha a VM felstartolna vagy legalábbis valami választ kapnának egy másodpercen belül.
• Több VM indításakor rettenetes lenne egyenként végigmenni a VMeken és mindegyikre kiválasztani egy szervert, elindítani. Talán 2-3 VM-mel elmegy, de 50-100 VM-mel idegesítő és lassú. Egy terv kell az összes startolt VM-hez, azok szükségleteinek és a hostok képességeinek megfelelően.

Hát ennyi röviden, szóval remélem az újévben erre lesz majd időm. Lenne utánna pár további ötletem, de olyan lépésben haladunk, hogy az már tényleg scifi kategóriába tartozna.

Hát szóval ennyit erre az évre, remélem tetszett ez a pár évvégi ötlet, esetleg megihlet pár sajátot.

A tömörítéssel kapcsolatos dologba belerúgtam egyet, ha érdekel mérések a dummy warhead-en. (tudátok, a "hibás-de-sebaj" angol blogom)

Akkor legyen ennyi erre az évre :)
Boldog újévet!

BS szótár: upstream és downstream

Egyes open source szoftverek esetében (pl ovirt) gyakran kerül szóba az upstream és downstream verzió, majdnem minden esetben amikor felhasználókkal beszélünk akkor a felhasználó visszakérdez hogy "Az up/downstream vajon mi?"

Cefet egyszerű: az upstream az a "community edition" megfelelője, a downstream meg a pénzes cók. Csak ezt így nem illik mondani :-)

oVirt lecke

Pár dolog, amit az eheti oVirt Workshop-on nyilvánvalóvá vált (legalábbis nekem):

• Az olyan környezetfüggőségek, mint a PostgreSQL és a JBoss nem hozzák közelebb az oVirt-et a felhasználókhoz. Sokan akarnák ez egészet egy kicsi környezetben futtatni, például tomcat-en vagy akár jetty-n. Akárcsak az appszerverből, adatbázisból sem szeretne a felhasználó hat félét a rendszerében. Meg tudom érteni...
  Söt a fejlesztők is így akarják.
• Tavaly ilyenkor még nem volt komoly verseny a nyílt forráskódú cloud management szoftverek között. Az oVirt is éppen publikálás elött állt. Azóta akkora szoftver-ajánlat jött létre, hogy az nagyon megnehezíti a felhasználók döntéseit. oVirt, Openstack, CloudStack, OpenNebula, satöbbi satöbbi. Nem hiszem, hogy ennyi szoftver túlélheti a versenyt, valaki rá fog faragni.
• Az OVirt UI nem rossz elsőre, de néhány helyen kicsit lehetne fejleszteni. A régi design-tól el kellene szakadni.
• A hibaüzenetek nem csak hogy nem elég jók, de néha kifejezetten gebasz.  pl "Nem sikerült elindítani a virtuális gépet" - és vajon miért?
• Feature-szinten azért minden kritikus és bomlasztó hozzáállásom ellenére szerintem egészen jól állunk, de az architektúrát ki kell pofozni, a ganajt ki kell hordani. Csökkenteni kell a fejlesztők extra terheit, különben a kutya sem akar majd beszállni buherálni.

Egyébként a ("rivális") cloudstack forráskódját olvasgatom, próbálgatom. Egyes dolgok marhára tetszenek, például hogy elmegy egy jetty-n, de van egy csomó dolog, ami tiszta marhaság. Pl a saját "IoC" rendszer, a belehegesztett mysql, stb.

Drools, Planner

Mostanában eltöltöttem egy kis időt egy prototipus projecten ami a drools planner integrációját késziti elő az oVirt-be. Ez még nem azt jelenti, hogy valaha benne is lesz, csak azt, hogy megpróbálom feltakarítani a környéket és beintegrálni. Gondoltam pár tapasztalatot megosztanék vele kapcsolatban.

Ha még nem találkoztál a drools projecttel, ez egy szabály-motor. Leírsz szabályokat, bedobálod a tényeket és bizonyos következtetésekre jut a drools, a következtetésekből pedig további következtetésekre. Egyrészt nagyon egyszerű és szerintem elegáns módja a szabályok leírásának, másrészt bizonyos bonyolult feladatokat egészen egyszerűen oldhatsz meg vele. Pl N királynő, labirintus, satöbbi iskolafeladatok. Na ezeken az iskolafeladatokon túl egész hasznos dolgokra is lehet használni a hétköznapi életben, most például az oVirt-ben (ami egy private cloud rendszer lenne, csak ahhoz még kicsit béna) virtuális gépek szerverekre való kiosztására próbálom használni.
(felemelő dolog szabadidőben is a melón pörögni, biztosan hősi gödörbe fognak elkapálni, ha beledöglök)

IDE

Szóval a szabályokat egy speciális nyelven írod le, erre van több opciód is. Ez végül sima plain java bytecode-dá fog lefordulni. Szóval ez forráskód, ha tetszik, ha nem. A forráskód, amit írnod kell java-jellegű. Éppenséggel én nem szeretnék ilyeneket írni vim-ben, szóval az IDE támogatásnak utánna kellett járnom.
Eclipse marketplacen ha szétnézel, a JBoss IDE állítja magáról, hogy van benne Drools support. Ez sima mezei hazugság marketing, nincsen benne :-) A drools csomagok közűl kellett letölteni egy lefordított verziót és felinstallálni. Pár varázslót és egy editort kapsz, az editorban van syntax highlighting és egy kevés code completion. A vim-élménynél azért lényegesen jobb, de el tudnék képzelni barátságosabbat.

Pár tapasztalat

Első alapszabály a drools-hoz általában: bármilyen szabályt írsz is, ne legyen benne hálózati/adatbázis interakció! A drools kegyetlenül elkapja és nagyon lassú lesz vagy agyonterheli az adatbázisod. Valószinűleg mindkettő. Csinálj szépen in-memory modelt. Elösször tölt, aztán kiértékel. Sajnos ez nem mindig egyszerű.

Aztán pl én néha nem szégyellek egy loggert bedobni a drools szabályaimnak, csak hogy meggyőzödjek róla, hogy tényleg kiértékelődnek. Érdemes csak debug szinten hajtani, mert komoly mennyiségű logot le tud termelni.


Aztán unit-tesztek: igen, mindenképpen unit-tesztelj! A szabályok csak futásidőben fordulnak le (első futás), szóval az hogy nem kiabált a build, az még a világon semmit sem jelent. És nagyon ajánlott ellenőrizni az eredményeket, mert könnyen előfordul, hogy elírtál egy feltételt a szabálynál és mégsem értékelődött ki.

A szabályok kiértékelési sorrendjáról pedig ennyit lehet tudni: javaslatot tehetsz rá (salience paraméter) de amúgy a drools nem enged beleugatni senkit se.

Planner

No nézzük mi ez a planner. A planner optimalizációs feladatokra segít adni valamilyen megoldást, a drools expertre építve. Ez konkrétan úgy történik, hogy pontozási szabályokat írhatsz le drools szabályokkal, írsz hozzá pár sor XML konfigurációt (ne aggódj, java config is van ha még nagyobbat akarsz szívni) és ráengeded a megoldó algoritmust. Visszakapsz egy megoldást jó esetben, és a hozzá tartozó elért pontszámot.

A pontozásnál több féle pontozást használhatsz, nekem a soft and hard tetszett legjobban.

Körülbelül ezer módon rúghatod tökön magad a drools plannerrel, kb 20 különbözőképpen nekem is sikerült, ebből párat nektek. Ha esetleg meg akarnátok próbálni :-)

Kiválló kiindulópont Geoffrey de Smet drools példagyüjteménye, ami a drools csomagok között letölthető. Szerintem a példagyüjtemény nélkül az elején feladatam volna. A dokumentáció az helyenként alulról közelíti a kettes érdemjegy határait. Pl az XML konfiguráció pontos leírását sehol se találtam, végül a forráskódból jöttem rá, hogy mit rontottam el.

Az egyik fájó különbség a példák és a rögvalóság között, hogy egyes példák egészen sokáig tart, amíg lefutnak. Sokkal tovább tart, mint a felhasználók türelme. A szerencse viszont az, hogy a legjobb megoldás a felhasználók túlnyomó részét teljesen hidegen hagyja, egyszerűen csak egy elég jó megoldást akarnak és persze tegnapra. Ezt sikerült olyan paraméterekkel elérni, mint

• maximumUnimprovedStepCount, azaz ha egy ideig nem talál jobb megoldást, akkor itt hagyjuk abba.
• scoreAttained, azaz egy bizonyos minimális szintnél tovább már nem kell tovább menni.

Azért a terminációs szabályokhoz én el tudnék képzelni jobb döntési logikát is, legalábbis az adott feladathoz én valami pontosabbat szeretnék. Majd bizonyíthatom, hogy tényleg van jobb ötletem, mert a drools planner-rel megetethetem a saját implementációmat.

Aztán nézzük mivel szívtam még meg... Igen, a probléma tények (facts)-hoz például első nekifutásra nem a megfelelő listát adtam vissza. Pár kört lefutottam, mire rájöttem, hogy ennek következtében a pontozási szabályok egyszerűen nem kerülnek kiértékelésre.

Aztán a ConstraintType.POSITIVE-ra nem jöttem még rá, hogy hogyan kell használni, a példák között nincs egy se. Pár dolgot viszont eleinte pozitív állítások formájában próbáltam megfogalmazni. Na erről leszoktam, és csupa negatív pontozás van jelenleg. Nekem furcsa, hogy csak büntetéseket osztok a szabályaimmal, de megszokom. Majd a politikai pályafutásom alatt biztosan sok hasznát veszem ezeknek a tapasztalataimnak.

Egyébként, ha kicsit belejön az ember, úgy tűnik egészen komplex feladatok optimalizására is egészen könnyen lehet megoldást gyártani vele. A futási ideje igazán nem vészes, amennyiben jól paraméterezted a termináló feltételeket :-)

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.

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é.

Kicsi a patched?

A Belgának van az a zseniális száma "Az a baj" címmel, pár apróbb módosítással tök jól leírja, hogy miért megy lassan az oVirt fdejlesztése. Ezer dolgon akadhat el minden, és persze el is akad. És ezek nem a szoftverfejlesztési kihívások mert az nem lenne gond, azért vagyunk itt.  Egyébként vannak csodák, csak nagyon ritkán, különben nem hívnák őket csodának :-)

Ha nem fetcheltél origint az a baj
Ha nem rebaseltél az a baj
Ha rossz branchen vagy az a baj
Ha kurva sok branched van az a baj
Ha a tököd kivan a gittel az a baj
Ha nem megy a gerrit az a baj
Ha nincs reviewer az a baj
Ha más patchen dependelsz az a baj
Ha túl nagy a patched az a baj
Ha nem írtál junit-tesztet az a baj
Ha rossz patchbe tetted az a baj
Ha az ezredik patchnél elbaszod az a baj
Én ezt a refactort másik patchbe tenném az a baj
Mindenki csak +1-et ad az a baj
Fastforward-policy az a baj
Kezdheted előről az a baj
Ettől nem lesz semmi se jobb az a baj

Szóval mégis mitől lenne gyors?

Developer Conference 2012 Brno, második nap

A fedora konferencia második napjáról jelentjük. Ma főleg (de nem kizárólag) JBoss előadásokat hallgattunk meg. Voltunk páran magyarok, többnyire magyarországi magyarok, a brnoiak csak néha tolták elő az orrukat :-)

Swimming Upstream - Jared Smith

A fedora project vezetője arról beszélt, hogy milyen egy ilyen linux disztró fejlesztését irányítani, igen ezzel az opensource dologgal nem zavarnálak titeket, de megemlítette valahol a java-t, beszéltünk az egyik szünetben és azt hiszem hasonlóan látjuk a helyzetet a fronvonal két szembenálló lövészárkából:
A java fejlesztők és a linux fejlesztők valamit kapni akarnak egymástól, de nem értik meg egymást és a végén senki nem kap semmit. Bukó, nem? Nyomozok a dologgal kapcsolatban, vannak fejlemények, majd mesélek egy másik posztban.

oVirt overview - Alan Pavec

Ez a munkám, imádatom és gyűlöletem tárgya, úgyhogy beültem hogy meghallgassam. Majdnem teltház volt a nagyteremben, örültem neki hogy ekkora érdeklődés volt. Sokan kérdeztek is. Remélem a hibákat sikerül kijavítani mielött ők is megtalálják...

RHQ4 - Lukás Krejci

Igen, a JBoss a redhaten belül egy külön ország. A java általában már csak így van. Szóval a RHQ-val java szervereket lehet igazgatni, több platformon keresztül. Lukás csinált jópár demót is, néha volt egy kis izgalom hogy most mi történik, de mindig jól sült el, pedig baromi nehéz live demót csinálni.

Whats new in JBDS 5.0? - Martin Malina

JBoss Developer Studio. Jaja, erről  a srácról csinálták ezt a vicces képet az üresnek látszó teremmel. Senki nem ült közel, mert akkor nagyon felfele kell nézni a kivetítőre. Közben én laptopon próbálgattam amit a srác mutatott (ugyanis nem vagyok pillanatnyilag képben jboss IDE-ből), meg is akadtam kicsit a forge konzolon, nekem ez ugyanaz volt, mint a springsource roo nevű cucca.

HornetQ - fastest JMS provider - Niroslav Novak

Ideje, hogy erdemben foglalkozzak a HornetQ-val. Ahogy néztem, könnyen beágyazható és szépen muzsikál. Igazából nem a sebesség az első és legfontosabb dolog, amit egy JMS szerver előnyei között fel tudok sorolni, de nem árt egyáltalán. Mondjuk nem annyira gyorsabb az ActiveMQ-nál. Érdekes lenne egy friss összehasonlítás, mit tudhat az ActiveMQ csapat új cucca.

Tomcat 7 and Tomcat 8 - Mladen Turk

Mit kaptunk a tomcat 7-től és mit kapunk majd a tomcat 8-tól? Állítólag a tomcat 7 sokkal jobb minőségű, mint a 6-os széria és ez a legfontosabb a legtöbb fejlesztőnek. (még nem találkoztam senkivel aki az async apit használta volna, annak ellenére hogy nagyon nagy dobásnak tartottam) A tomcat 8 olyan dolgokat tartogat, mint websockets... amire semmilyen standard api nincs, de legalább történik valami.

Egyéb...

Egyébként volt kaja, volt innivaló (kólás pohárból kofola, király), esti parti és voltak magyarok is, Magyarországról jöttek hárman. Páran nem mertek elindulni a hazai úthelyzet miatt sajnos. De akik jöttek, azokkal jót vitatkoztunk pár kérdésben :-)

A 'Presentation Skills' tanárnőt láttam mászkálni a kamerájával, aligha a linux kernel érdekelte, szerintem megpróbálja majd a geek-eket kicsit rocksztárosabbra faragni. Nem baj, rájuk fér :-)

Developer Conference 2012 Brno, első nap

Tegnap a brnoi fejlesztői napon voltam, csak pár prezentációról, ami nagyon tetszett...

Towards Unified Messaging - Frantisek Reznicek

A csákó az AMQP protokolról és az apache qpid-ról beszélt. Az AMQP egy szabvány message queue-knak, nekünk a JMS protokol miatt nem volt különösebben fontos, hogy protokol szinten szabványos legyen. Elég volt kicserélni a drivert és kis szerencsével működött. Mindenesetre egy egész tucat JMS szerver implementálja ezt a szabványt most már. Pl az ActiveMQ és a  is.

Richfaces: testing on mobil devices - Pavel Pitonak

Érdekes demó a QE csapattól arról, hogy hogyan automatizálják a tesztjeiket mobil eszközökre virtualizált szerverekkel.

What are Drools, Guvnor and Planner - Geoffrey De Smet

Java témában kb etalonnak számító rules engine és a köré épített projektek. Semmi új nem volt nekem, decemberben elkezdtem egy prototipis projektet az oVirt mellett kisérletezésre és az egészen Drools-ra épül. Geofrey viszont jó előadó és a többiekkel ellentétben nem akadozik és nem dadog. Ja meg cseh akcentusa sincs :)

A drools érdemel talán egy kicsit nagyobb figyelmet, szerintem sok gyakori problémát le lehet vele egyszerűsíteni.

Hibernate OGM - Michal Linhard

Ez egy jelenleg alpha állapotú project arra, hogy sima JPA apival és annotációkkal ne csak hagyományos relációs, hanem NoSQL jellegű adatbázisokba is lehessen perzisztálni. Jelenleg csak az infinispannal megy, de az infinispan mögött lehet akármi is: cassandra, mongo, akár relácis adatbázis vagy filerendszer is.

Ez nagyon tetszett, nem tudom hogy fog elsülni ez a próbálkozás, de marha jó ötletnek tartom. Kiváncsi vagyok tényleg sikerülhet-e a gyakorlatban, hogy kihúzod az appod alól a relációs adatbbázist és kicseréled valami NoSQL-re.

Continuous integration with Jenkins CI - Vojtech Juranek

Trükkök Jenkinssel. Virtuális szervereken futó agentek, egzotikus nyelvek (php például), bug detektor pluginok. Mondjuk a statikus analízisre én a sonar-t tartom a legjobbnak, az nagyon pöpec.

Csak én tartom igénytelennek a jenkins webes felületét? Jó, úgyis csak fejlesztóknek kell, de ha ennyien használjuk, nincs egy designer köztünk?

No, most jön a második nap, ma oVirt, GlusterFS, SPICE további JBOSS előadásokat fogok hallgatni.

VDay 2011 Budapest

Pénteken Budapesten voltam a VDay konferencián. Ingyenes konferencia létére marha jó, minőségi konferencia volt. Nulla bullshitelés, live demók és valós tapasztalatok, nem pedig marketing-fényezés. Gondoltam röviden beszámolok azoknak, akiket érdekelt volna de nem tudtak eljönni.

Klock László - Amit tudni akartál a vShieldről de soha nem merted megkérdezni

A vShield architektúrális felépítéséről és történetéről, biztonsági hibáiról. Hát ami igaz az igaz, rendesen le lett szidva a vShield. A hibák súlyát átérzem, de nem nagyon tudok hozzászólni mert soha nem használtam. Na és persze nem jött meg a bátorságom az előadástól.

Zrubecz László - VmWare vCenter Server Applience - vCenter linuxon

Másik VmWare technológia, amivel soha nem foglalkoztam :) Ezt tudtam meg róla: már régebben volt egy ilyen szoftvere a VmWare-nek, de abbahagyták és Windows-on árulták inkáb. Most, hogy a Microsoft inkáb a Hyper-V-t szereti, a VmWare is újragondolhatta a stratégiáját és most előjöttek újra a linuxos termékkel. Ez tulajdonképpen egy java-s webapp tomcaten (szóval ha egy ici-pici időt rászántak volna, mehetett volna ez a termék egyébként) alatta DB2 adatbázissal. Na ezen nem csak én buktam ki, hanem kábé mindenki. A DB2-vel horror-élményeim vannak. Láttam már mindenféle adatbázis szerverből hardware meghibásodás nélkül hanyattfeküdt példányt, de DB2-ből láttam a legtöbbet ahhoz képest hogy mennyire ritka egyébként.
Nos emellett a vCenter linuxos verziójának volt pár elszúrt része: iptables üresen, install csomagok rajtahagyva, statikus méretű partíciók a lognak és idióta syslog setup az stunellel. Hát, elég sok munkát ad még egy embernek ez a cucc, mire tényleg használhatóvá válik. De legalább van, a következő verziókban remélhetőleg meghallgatják a felhasználók imáit.

Lajkó Attila - A Red Hat Enterprise Virtualization 3.0 újdonságai

Ez a prezentáció érdekelt a legjobban (ugyanis ezen a szoftveren dolgozok napi 8+ órát). Kicsit mosolyogtam magamban amíg Attila a screenshotokat mutogatta, mert tudtam hogy a windowsos (.Net-es) user interfaceről készült képeket látjuk, egy ponton Attila ezt meg is említette. Na ekkor egyszerre 3 különböző embertől hallottam valami olyasmit hogy "Pffff..." :-D Hát ez van, de persze jön a szép GWT-s felhasználói felület, a srácok ott írják elöttem. Amúgy az újdonságok: multi level administration, host hooks, rest api, satöbbi. Nekem kicsit hiányzott az oVirt az előadásból, de nem kellett arra se sokat várni.

Kunszt Árpád - IPv6 biztonsági kockázatok

Hát, mégegy előadás, amintől okosabb és boldogtalanabb lesz az ember. Pár demóval (pl hup.hu hijack) megfűszerezett beszámoló. Nem szivesen lennék hálózati rendszergazda, de tágult a tudatom.

Deim Ágoston - Futás a végtelenbe

Ago eredetileg egy munkatársával ketten akarta bemutatni linuxos és windowsos virtualizációs megoldásokat, kvm vs hyper-v. A kolléga viszont beteget jelentett, így csak kicsit lettem okosabb a Hyper-V-vel kapcsolatban (sebaj, úgyse veszek windowst) jópár élő demót láttunk viszont a kvm parancssori és grafikus felületeiről. Egy ponton Ago az oVirt-et is megemlítette (Köszi Ago!), mint érdeklődésünk potenciális célpontját, amennyiben elég bátrak és türelmesek vagyunk hozzá. Azért ne aggódjatok, nagyon dolgoznak rajta a srácok, lesz packagelve mindenféle distróra: ubunturól, gentoo-ról és suse-ról tudok. (a fedora _nyilván_ beleértendő :-) ) Szóval csak a nagyon egzotikus disztrókra kell sokat váni talán.
Ago előadása egyébként talán a legszórakoztatóbb volt pedig a többi előadó is jó szöveget nyomott. Például amikor su - után mégse kért jelszót a szerver, de Ago elkezdte begépelni a jelszóként használt trágár szót a kivetítőre párszáz ember elött, az elég tréfás volt :-)

Egyéb

Több előadó használta az "Enterprise" szót pejoratív értelemben. Ezt meg tudom érteni. Sajnos viszont a java programnyelvet is lenézően említették. Szomorú, nem kellene, hogy így legyen. Az hogy java-ban programozunk, nem jelnti azt hogy totál idióták vagyunk. Legalábbis azt még nem.

Volt gépmutogató asztal, az Inteles srác mutogatta a félelmetes virtualizációs célszervert, amibe egy unitba 16 core és 196 GB memória passzol, és persze 6 unit fér el benne. Közös SAS diskarray és beágyazott management rendszer. Szóval egy atomerőmű. Gondoljatok csak bele mennyi passziánsz futhat ezen, már alig pármillió forintért.

A szomszéd teremben esküvőipari konferencia zajlott. Gázul hangzik, remélem soha nem leszek az ügyfelük.

Valamint baró jó volt a hazai kaja. A csehek nagyon tudnak élni de én a szakácstudományukat nem tudom annyira értékelni :-) Ezt ne mondjátok meg nekik! :-D

oVirt @ Budapest

November 25.-én (péntek) lesz Budapesten a vday konferencia, amin Lajkó Attila, az ULX embere fog beszélni a Red Hat Enterprise Virtualization 3 (ahogy mi ismerjük RHEVM, de ne lepődjetek meg rajta, ha nogah, vdc, rhev vagy egyébb elnevezéssel találkoztok bárhol benne) újdonságairól. Remélem nem lövöm le az előadó egyetlen poénját sem, de az egyik újdonság az, hogy most már nyílt forráskódú oVirt néven. Az IRC csatornákon komoly tevékenység zajlik, vannak akik más rendszerekre (pl debian) csomagolják, sokan tesztelnek, satöbbi-satöbbi.
Ingyen konferencia, de több nagy játékos lesz jelen: Vmware, Microsoft, Novel, Citrix - szóval remélem nem lesz marketing bullshot. Annyira bízok benne, hogy én már be is regeltem, és kaptam rá egy munkanapnak számító napot. Biztos móka lesz megnézni hogy más milyennek látja a rendszert.
Ha jöttök, majd fussunk össze!