Miért nincs valódi állapotfogalom az IaC-ben? És mit old meg ebből a CIC?

Fejlesztés

Az IaC eredetileg azt ígérte, hogy a deklarált leírásból és a valós infrastruktúraállapotból meg lehet határozni az eltérést.
A gyakorlatban azonban ez sosem működött igazán — és ennek oka egyszerű: az IaC-ben valójában nincs állapotmodell.

A deklaráció szándék, de nem állapot.
A valós rendszer állapota pedig nem vezethető vissza egyetlen IaC-fájlra vagy futtatásra sem.

Nincs Intent → nincs State → nincs következetes összevetés → nincs determinisztikus következménykezelés.

És itt jön képbe a CIC (Central Infrastructure Core) szemlélet, ami nem YAML-ekkel vagy szkriptekkel akar harcolni, hanem logikai modellel:

  • Actor – ki teszi a változtatást
  • Intent – mit akar elérni
  • State – milyen állapotot hoz létre vagy módosít
  • Obligation – milyen kötelezettségeket generál
  • Consequence – milyen következménye lesz
  • ProofTrace – bizonyítható lánc minden lépésről

A CIC lényege nem az eszköz, hanem a relációs modell:
az elvárt állapot és a tényleges állapot logikailag összevethető, mert mindkettő formálisan létezik a modellben.

A Relay réteg pedig gondoskodik arról, hogy az állapot átadása determinisztikus legyen — nem pipeline, hanem állapotöröklés.

💬 Vitára fel:

  • Szerintetek az IaC miért nem tudja valójában összevetni az elvárt és a meglévő állapotot?
  • Terraform state valóban állapot, vagy csak „futtatásközi tároló”?
  • Van-e ma olyan eszköz, amely formális Intent-modellt használ?
  • Ti milyen problémába futottatok bele a „valós vs deklarált állapot” területen?

Ha van rá igény, hozok példát konkrét Intent–State–Consequence láncra a CIC-ből.

  • 1091 megtekintés

( yetii | 2025. 11. 14., p – 08:42 )

Első körben definiálnod kellene, hogy számodra mit jelent az állítás, hogy "nincs állapotmodell". Ugyanis nyilvánvalóan a legelterjedtebb IaC solutionökben (terraform/tofu, pulumi, CloudFormation/CDK etc.) van, de úgy tűnik, hogy valamiért az nem felel meg a követelményeidnek.

Alapvetően 2 okból van szükség az állapotra egy IaC tool esetében:

  • mapping: a desired state config-ot (azaz a deklaratív leírása a rendszernek) valamilyen módon le kell mappelni arra, hogy valójában milyen fizikai (legalábbis ebben az értelemben fizikai, amúgy kb 48 réteg vírtualizáció fölött van :D ) resource-ot reprezentál. Ezt azért kell egy független "state"-be menteni, mert ha provider és cloud agnosztikusak akarunk lenni, akkor nem feltételezhetünk semmit arról mi a resource amit kezelünk, és hogy azt a resource-t bármiféle mapping nélkül hozzá tudjuk-e rendelni a desired state configunkban definiált resourcehoz, vagy hogy tudunk esetleg olyan metaadatot tárolni hozzá ami alapján ezt meg lehetne csinálni. Ellenpéldaként ott van az Ansible, ahol ezt pont megpróbálták, de az kicsit más rétegben dolgozik, és az én véleményem szerint pont ez az egyik oka, hogy elég nehézkes lett az egész egy idő után.
  • egyéb metadata tárolására, ami önmagában nem reprezentálódik az infrában, de segíti, hogy konzisztens és reprodukálható legyen egy infra. Pl passwordök, timestampek etc. generálása, ami megmarad futások között ha jól definiáljuk.

 

Szóval kíváncsi vagyok, hogy miért gondolod, hogy ez a megközelítés hibás, és nem egyszerűen a probléma komplex, ami miatt nehéz ezt helyesen kezelni, és más modell-re van szükség a jelenlegi általánosan elterjedttel szemben amit mondjuk a terraform használ.

más modell-re van szükség a jelenlegi általánosan elterjedttel szemben amit mondjuk a terraform használ.

A százmillió forintos kérdés pedig, hogy még ha a Terraform éppenséggel nem lenne kielégítő, mennyivel leszünk előrébb egy gyakorlatilag nem létező új modell bevezetésével.

Lesz hozzá tooling? Lesz hozzá szakértelem a munkaerőpiacon? Stb.

Jelenleg van egy elméleti dokumentáció és egy chustome prompt ami ezt egészen emberien el tudja magyarázni

Tehát gyakorlatilag nincs semmi. Ez a projekt akkor lesz érdekes, hogy mondjuk megmutatom egy sandbox környezet mostani toolingját, te/valaki pedig megmondod/-ja, 

  1. hogy lehet kiváltani ezzel a CIC-valamivel, illetve
  2. miért lesz ez nekem jó.

Utóbbit lehetőleg euróban kifejezve, hogy a döntéshozók is értsék.

menjünk akkor részletekben... mivel a jelenlegi tool bokrétát nem írtad le ezért én dobom fel mi az én koncepciómat amit szeretnék megvalósítani
tervezett PoC:
v1 proxmox alatt vyos+debian bastion vault-tal+relay-el 
v2 v1+ managment talos cluster (relay+vault+nexus+gitea+cloudnative_pg) 
v3 v2+ 2 telephely hasnoló kiépítéssel

mit fog demostrálni ez:
- kezeli a műveletek mögötti szándékot, a következmény-modellt vagy a bizonyítható auditláncot.
- képes valós időben, futás közbeni bizonyítékkal alátámasztani 
- egységes szándék- és következményalapú bizalomláncot épít egy komplexebb rendszerben is 

Kimondható hogy a CIC bizonítékalpú rendszer nem pedig desired state építő környezet

 

 

Köszönöm a részletes választ, és akkor pontosítok, hogy mit értek „nincs állapotmodell” alatt — mert valóban nem a Terraform-féle state-fájl létezését vitatom.

Az IaC-ben van state, de nem állapotmodell, és ez a különbség a lényeg.

1) Az IaC „state”-je mapping- és metadata-tároló, nem állapotmodell

A Terraform/Pulumi/CFN state:

  • resource-azonosítók,
  • provider-mapping,
  • függőségek,
  • metaadatok (token, timestamp, hash stb.).

Ez egy műveletközi tároló, nem egy absztrakt rendszerállapotot reprezentáló modell.

A state nem írja le:

  • az Actor szándékát,
  • a célállapotot mint logikai struktúrát,
  • a változás következményeit,
  • az ebből fakadó kötelezettségeket,
  • a valós állapot és a kívánt állapot közti szignifikáns eltéréseket.

Tehát: state létezik → állapotfogalom nincs.

2) Az IaC “desired state” nem összevethető a tényleges állapottal

A deklarált konfiguráció → szándék leírása, nem állapot.
A valós infrastruktúra → tényleges állapot, ami:

  • driftelhet,
  • módosulhat IaC-n kívül,
  • bővülhet vagy zsugorodhat más rendszerek hatására,
  • lehet részben felkonfigurálva,
  • lehet dependency-szinten eltérő.

Az IaC saját definíciója szerint sem végzi el a valós és az elvárt állapot tiszta összevetését, csak diffet számol a deklarációhoz képest, feltételezve hogy a state reprezentálja a valóságot — ami sok esetben nem igaz.

3) A CIC állításának alapja: az IaC modelljéből hiányzik az Intent → State → Obligation → Consequence lánc

A CIC szerint egy valós állapotmodellhez négy dolog kell:

  1. Actor – ki generálja a változtatást
  2. Intent – mit akar létrehozni
  3. State – formális állapot (nem provider-mapping, hanem logikai rendszerállapot)
  4. Obligation – milyen kötelezettséget generál az Intent
  5. Consequence – mi történik, ha a tényleges állapot eltér
  6. ProofTrace – bizonyítható lánc

Ezek közül egyik sem része az IaC-modellnek, így a drift kezelése mindig:

  • eseti,
  • eszközfüggő,
  • részleges,
  • regresszív (tuning helyett workaroundokat épít).

A CIC nem azt mondja, hogy az IaC „rossz”, hanem azt, hogy a deklaráció önmagában nem elég az állapot reprezentálásához.

4) A komplexitás önmagában nem indokolja a hiányt — csak azt mutatja, hogy a jelenlegi modell nem alkalmas rá

Idézlek:

„nem egyszerűen komplex-e a probléma?”

A probléma komplex, igen — de ettől még lehet rá olyan modell, amely ezt kezeli.
A CIC fogalmi tere (Actor → Intent → State → Obligation → Consequence) éppen ezt teszi:

  • különválasztja a szándékot az állapottól,
  • különválasztja a kívánt állapotot a tényleges állapottól,
  • és definiálja a következménylogikát a kető közötti eltérés esetére.

Ezzel az IaC-ben lévő implicit drift mechanizmus → explicit állapotmodellré válik.

5) Röviden összefoglalva

Az IaC „state” nem állapotmodell, mert nem ír le egy absztrakt, összevethető rendszermodellt.
A CIC pedig azt mondja: egy infrastruktúrát csak akkor lehet determinisztikusan kezelni, ha a szándék, az állapot és a következmények formálisak.

Ezért használ más szemléletet.

Bocs, ezen a ponton muszáj megkérdeznem: ez a te véleményed, vagy az AI-é? Le tudod írni a saját szavaiddal a saját véleményedet? Te, mint ember, megértetted, miről szól egyáltalán ez az egész?

Magának a "modell" szónak a jelentésével tisztában vagy amúgy? A modell nem kell hűen tükrözze a valóságot, hanem egy egyezményes "elégséges" szintig kell reprezentálnia a valóságot az elvégzendő műveletek szempontjából. 

a deklaráció önmagában nem elég az állapot reprezentálásához.

Miért? Légyszi, ne az AI írja meg, hanem te. Miért gondolod te, mint ember úgy, hogy ez kevés? Neked, mint embernek mi ezzel a problémád?

Alapvetően a deklaráció ugyanis nem a mindenkori állapotot írja le, hanem a "desired state" állapotot - ami nálad ha jól értem, az "intent" -nek felel meg. 
A terraform esetében a terraform tool (actor) a definíciót és a definició alapján felépített állapot modellt hasonlítja össze, ez alapján felméri, hogy mit kell csinálnia a vágyott állapot eléréséhez (obligation) majd azt végrehajtja (consequence).

Az "IaC state" -nek nem is műlhatatlanul egy teljes rendszermodellt kell leírnia. Optimális esetben persze, ha az egész infrastrkúrát ground-up IaC-vel készítenénk el, akkor igen, de pl a hardvert nem tudod IaC definiálni, az operációs rendszert megint nem tudod (csak korlátok közt), stb. tehát akármilyen "állapotmodellt" készítesz, az szükségszerűen nem lesz mindenre kiterjedő.

Maga az IaC lényege épp az, hogy a rendszernek csak azt a részét modellezzük, amivel aktuálisan foglalkozni szeretnénk, nem feltétlenül az egész rendszert. De lehet félreértek valamit. 

Örülnék, ha nem AI választ írnál.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

nézzük annyira nem bonyolult az egész viszont a végrelenségig lehet építeni szóval az.
Vannak a relay-ek ami adja a rendszer magját a kommunikációs ráteget és magát az OIS bizonyítási réteget (agy kicsit megkeverve a digitális aláírás). ezen a rétegen futtnak a modulok workflow leírások alapján. Maguk a moduloknak 3 fő funkciójuk van 1. set 2 get 3 notify azaz set: létrehoz beállít, get lekérdez notify: triggerel egy workflot mely mondjuk elindít egy lekérdezést ami felküldi a központba a változtást.

Maga a CIC azt teszi le az asztalra hogy amit felügyel annak az állapotát is ismeri, nem le tudja kérdezni hanem valahol mondjuk egy IaC state branch-en tárolva van... úgy hogy az elvárt állapotból (pl. IaC main branch) származtathatóés ezáltal a diffek egyszerűen detektálhatóak kezelhetőek benne és mivel minden IaC-ben pontosabban git alatt van ezért verziózott és dokumentáltá lehet tenni gyakorlatilag minimális erőforrás befektetéssel.

Igy az IaC state optimális esetben a kezelt obj-k azonosítóival kiegészülve érdemben egyenlő az IaC main adataival (mivel git azaz TXT ezért a sorrend is bejátszik....)

elfgoadom, ti kértétek hogy AI nékül írjak és itt az elméletről beszélgetünk és az meg deffiniciók nélkül meg hogy is mondjam annyi lenne hogy: elméletben működik szép és kerek :P 
gyarkolatban: relay megkapja az adatfolyamot amit tovább kell passzolnia továbbítja amit fel kell dolgoznia az elkezdi feldolgozni: beolvassa a yaml mely modullal kell dolgoznia haa modul még nincs beolvassa akkor a meta adatok alapján validálja a wasm binálist mejd beolvassa, a modul meta adatai között benne van az input schemál melyek alapján validálja az adatfolyamot és ellenőrzi a jogosultsági szinteket... közben párhuzamosan ellenőrzés után példányosítja a wasm modult mely megkapja az adathalmazt ami alapján a modul elindítja a belső folyamatait és eredményről megy a visszajelzés a kérelmezőnek. Ha netántalán váltzoás van a szolgátlatás beállításaiban akkor vagy a szolgáltatás vagy az operációs rendszer meghívja a megfelelő notify végpontot ami mondjuk visszaolvassa az aktuális állapotot és visszaküldi a központba.

Reméleg érthető és nem lett túlontúl teknokrata

amit felügyel annak az állapotát is ismeri, nem le tudja kérdezni hanem valahol mondjuk egy IaC state branch-en tárolva van...

Pontosan ez az, amit a Terraform is csinál. Alapvetően a Terraform azt csinálja, hogy a "kódban" leírt vágyott állapotot lefordítja a konkrét providerre specifikusan (plan), ezt összenézi a tényleges beállításokkal, hogy össze tudja állítani az elvégzendő módosítások listáját. Amikor vége a módosításoknak, akkor az eredményül előálló állapotot rögzítjük egy terraform state fájlban, ez reprezentálja a felhőben levő állapotot.

Ez a state fájl szükségképpen csak annyira lesz teljes körű, amennyire a kiinduló IaC kód az volt. Ha az IaC csak RDS instance-ket hozott létre, mert az EC2 gépeket kézzel csináljuk (akármiért) akkor az EC2 -k nem lesznek benne, hiszen az IaC által kezelt infrának azok nem részei.

Egy ilyen IaC -nél azonban időnként mindenképpen le kell diffelni az elmentett state fájlt a tényleges állapotokkal, egyszerűen azért, mert bármilyen állapotmodell szükségképpen egy "fénykép" egy valamikori állapotról. Ha azóta bármi megváltozott, azt érzékelni és kezelni is kell tudni. Mindazonáltal, mindaddig, amíg nem akarunk operatívan beleavatkozni az infrastruktúrába, az állapotmodell alapján lehet tervezni, analizálni, stb.

Az Ansible esete azért tér el egy kicsit, mert neki már el kell tudnia kezelni az IaC-n kívülről jövő állapotváltozásokat is. És ez nem feltétlenül rossz dolog, vagy a rendszer ellen van. Pl, ha van egy auto-update folyamat, az elképzelhető, hogy kívülről, az Ansible kontextusától függetlenül módosítja a gép állapotát (frissít egy csomagot), így az állapot modell instant elavult lesz. Ez az IaC szempontjából egy szerencsétlen esemény, de az üzemeltetés szempontjából meg pont hogy kívánatos, hiszen az IaC -nak nem feladata a gép naprakészen tartása (secu szempontból).

Így az IaC state optimális esetben a kezelt obj-k azonosítóival kiegészülve érdemben egyenlő az IaC main adataival

Nem teljesen. Az IaC state az a legtöbb esetben nem provider-agnosztikus, hanem a tényleges állapotot tárolja le a tényleges provideren. Ha nekem van egy olyan IaC eszközöm, ahol le tudok definiálni mondjuk database, database_user, database_permission objektumokat, akkor a plan az lehet érdemben egyenlő az IaC main adataival, de a state már a tényleges állapotot kell tükrözze, ami viszont fel van gazdagítva a provider által lekérdezett adatokkal. Ebben az esetben a state tehát több lesz, mint ami az IaC main-ból egyenesen következne.

És így a végére engedj meg egy kis rantelést. Tök szép meg tök jó ötlet ez az IaC dolog, azonban az üzemeltetés egy nagyon gyakorlatias művészet, ahol a tényleges üzemeltetési igényekhez igazítunk minden elméleti cuccot. Ez azt jelenti, hogy nem szükségképpen fogjuk az eszközöket az ideális módon használni. Pl nekem most van egy infrám, ami most kerül be IaC alá, és utólag sakkozok a state-tel, meg ignorálok attributumokat, hogy az IaC ne bontsa el a meglevő node-okat, csak kreáljon újabbakat. Mert ez egy "legacy" cucc abban az értelemben, hogy maga az infra alapjai nem IaC -vel lettek elkezdve. Ez szembe megy egy csomó dologgal, ami az IaC elméletében le van fektetve, azonban nekem nem elméleti infrákat kell üzemeltetnem, hanem olyanokat, amik tényleges vason futnak. Így igenis elvárás egy IaC eszköztől, hogy képes legyen lekérdezni és figyelembe venni a tényleges, valódi állapotot is, és valamelyest képes legyen összevetni az IaC kódban megfogalmazott vágyott állapotokkal. Nem azért, mert az elmélet megköveteli, hanem mert a gyakorlatban van erre szükség.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

én a terrafornnál azt nem tudtam megérteni hogyha felépítem a logikát ami az IaC-ből csinál infrát és megvan a tfstate amit tényelgesen létrejött akkor ezt miért nem lehet folyamatosan fentartani... megvan az eszközkészlet csak az igény nem volt meg rá... sajnos.... illetve a tfstate formátuma kb köszönő viszonyban van csak az eredeti IaC formátumával....

Mit jelent a "folyamatosan fenntartani"? A te rendszeredben hogy néz ki az, hogy van valamilyen állapota a cloud landscape-nek, én meg bemegyek az AWS root accounttal, bedurrantok valami új resource-t kézzel, kitörlök egy másikat, átrendezem a tag-eket, stb.

Ezt hogy követi le a te megoldásod?

Sehogy, az IaCnek nem célja az, hogy a clickops által létrehozott változtatásokat beépítse a configba. Ez egy drift lesz, ha egy létező IaC által kezel resourcet érinti a változás, akkor vissza lesz vonva, ha nem, akkor pedig teljesen láthatatlan lesz IaC szempontból.

Azt értsd meg, hogy ahol IaC-t használunk, ott a clickops műveletek nem támogatottak: lehet olyat csinálni sürgős/kivételes esetben (bár vannak helyek, ahol nem is lesz root accounthoz access-ed, mert konkrétan minden változtatást csak IaC-n keresztül tudsz végrehajtani, minden más út le van korlátozva), de olyankor mindig vissza kell vezetni a változtatást az infra kódban, mert a desired state-ed megváltozott! Amúgy vannak eszközök az ilyen driftek kezelésére (pl a firefly.ai), de ezek az IaC toolok felett működnek, nem helyett (másik példa, kicsit más domain, bár az is IaCnek tekinthető: fluxban image automation controller sem a deploymentben írja át közvetlenül az image tag-eket, hanem a gitops repóban változtatja a desired state-et!).

A te rendszeredben hogy néz ki az, hogy van valamilyen állapota a cloud landscape-nek, én meg bemegyek az AWS root accounttal, bedurrantok valami új resource-t kézzel, kitörlök egy másikat, átrendezem a tag-eket, stb.

Hehe... dolgoztam olyan cégnél, ahol nem volt clickops lehetőség, minden le volt korlátozva, a gépeken az SSH is úgy volt beállítva, hogy ha valaki véletlenül belépett, akkor a belépés ténye terminálta az egész gépet, mert az ilyenkor "dirty" lett. :D

https://iotguru.cloud

Szerintem leírták a választ. Az IaC által managelt resource-ok visszakerülnek eredeti állapotukba (reconciliation), amit pedig nem kezel az IaC, és kézzel lett létrehozva, az ottmarad.

Ha kézzel belemókolunk valami feloldhatatlan függőséget akkor pedig az IaC felteszi a kezét :)

De nyilván ezt te is tudod, szóval mi a kérdés mögött a kérdés? :D

Volt egy ilyen: "én a terrafornnál azt nem tudtam megérteni hogyha felépítem a logikát ami az IaC-ből csinál infrát és megvan a tfstate amit tényelgesen létrejött akkor ezt miért nem lehet folyamatosan fentartani..."

Azt kérdeztem, mit jelent az, hogy "folyamatosan fenntartani" (a mit is?). Nem volt semmi rejtett üzenet a kérdésben, csak érdekelt, hogy ha a tfstate szar, mert* ha kézzel szétgórom, akkor nem követi le magától, akkor hogy oldja ezt meg a CIC?

(* vagy legalábbis ezt olvastam ki a kommentből, aztán lehet, félreértek valamit – ezért is lenne jó pontosítani)

Hogy oldja meg a CIC? 
Sehogy. Átnéztem a linkelt github repót, az alapján azt értettem meg, ez valami univerzális megoldás kíván lenni a mindenre is, de leginkább AI slopnak tánik a tartalom olyan 90%-a. 

Ennyit találtam ehhez:
4. Nincs workaround – csak szabályos megoldás
Ha valamit „külön kell kezelni”, akkor a rendszer nem tudja garantálni a működést. Minden entitás vagy része a gráfnak, vagy nem.

Szóval ha valami miatt kézzel kellett mókolj, azzal a CIC nem tud mit kezdeni. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Ne haragudj, de ez egy nagy bullshit, semmi indoklást nem tartalmaz arra nézve, hogy a terraform ennek miért nem felel meg (illetve más IaC solutionökre ezek ugyanúgy igazak, pl a Pulumi modellje nagyon hasonló). Lássuk csak részletesen:

A state nem írja le:

  • az Actor szándékát,
  • a célállapotot mint logikai struktúrát,
  • a változás következményeit,
  • az ebből fakadó kötelezettségeket,
  • a valós állapot és a kívánt állapot közti szignifikáns eltéréseket.
  • A terraform modellben nem a state írja le az "Actor szándékát", hanem konkrétan a terraform leírók a desired state config.
  • Nem igazán értem, hogy számodra mi a különbség a szándék és a célállapot között. A szándék a célállapot. Nyilván nem a részletes config az üzleti igény, de ezeket az absztrakciókat neked kell kiépítened terraform resource-ok fölött a megfelelő module-okkal, a terraformnak mint toolnak nem célja ezt helyetted definiálni, mert nem tudhatja, főleg, hogy ő csak egy modellt ad, amit a különböző célplatformokat megcélzó providerek implementálhatnak célszerűen a platform által nyújtott APIknak megfelelően. Erre aztán a terraform által nyújtott eszközökkel úgy definiálsz abasztrakciókat, ahogy neked jól esik, illetve felhasználhatod a kismillió fizetős szolgáltatást/solutiont, akik már megcsinálták ezt helyetted, és építhetsz arra közvetlenül.
  • "a változás következményeit, az ebből fakadó kötelezettségeket" ez nem célja a terraformnak, nem is vagyok benne biztos, hogy értem, hogy mire gondolsz ez alatt, egy példa jó lenne rá.
  • "a valós állapot és a kívánt állapot közti szignifikáns eltéréseket." Pont ez a lényeg, hogy a valós állapotot NEM KELL tárolnunk az ott van valahol, amit fel tudunk térképezni, pont ezért kell egy mapping a terraform által kezelt virtuális resource-ok és a fizikai resource-ok között, mert szükségszerűen a terraform state nem tartalmazhat mindent, de nincs is rá szükség, mert a valós rendszerből le tudjuk kérdezni az aktuális állapotot.

2) Az IaC “desired state” nem összevethető a tényleges állapottal

A deklarált konfiguráció → szándék leírása, nem állapot.
A valós infrastruktúra → tényleges állapot, ami:

  • driftelhet,
  • módosulhat IaC-n kívül,
  • bővülhet vagy zsugorodhat más rendszerek hatására,
  • lehet részben felkonfigurálva,
  • lehet dependency-szinten eltérő.

Az IaC saját definíciója szerint sem végzi el a valós és az elvárt állapot tiszta összevetését, csak diffet számol a deklarációhoz képest, feltételezve hogy a state reprezentálja a valóságot — ami sok esetben nem igaz.

Ezzel semmit nem mondtál, senki nem mondta, hogy a desired state a tényleges state, de a végkövetkeztetésed teljesen ellentmond magának: a diff pont hogy a valós és az elvárt állapotot hasonlítja össze, ez a lényege a desired state confignak, hogy nem a valóságot írjuk le, hanem azt, hogy mit szeretnénk elérni, a state pedig csak egy mapping a leíró és a valóság között (legalábbis ha már volt apply-olva a config). Az pedig igenis a te felelősséged, hogy a valóság ne drifteljen el a desired state-től olyan módon, ami a terraformban driftként jelenik meg: úgy kell definiálni a desired state-et, hogy a legális változások ne okozzanak driftet!

3) A CIC állításának alapja: az IaC modelljéből hiányzik az Intent → State → Obligation → Consequence lánc

A CIC szerint egy valós állapotmodellhez négy dolog kell:

  1. Actor – ki generálja a változtatást
  2. Intent – mit akar létrehozni
  3. State – formális állapot (nem provider-mapping, hanem logikai rendszerállapot)
  4. Obligation – milyen kötelezettséget generál az Intent
  5. Consequence – mi történik, ha a tényleges állapot eltér
  6. ProofTrace – bizonyítható lánc

 

Ez full bullshit, itt semmit nem mondtál. 

  • Miért érdekes, hogy "ki generálja a változtatást"?
  • Mit jelent az intent számodra, ha nem azokat a resource-okat, amiket létre akarunk hozni?
  • Mit tartalmaz a formális állapot, ha nem a mappinget, és mit nyerünk vele, hogy ugyanazt az állapotot kezeljük, ami a providerben natív módon létezik?
  • Obligation: ez mi, és mi haszna van számunkra?
  • Consequence: szintén mint egyel fentebb, miért hasznos ez nekünk?
  • Proof: mit szeretnél bizonyítani? Mit nyerünk ezzel?

Ezek közül egyik sem része az IaC-modellnek, így a drift kezelése mindig:

  • eseti,
  • eszközfüggő,
  • részleges,
  • regresszív (tuning helyett workaroundokat épít).

A CIC nem azt mondja, hogy az IaC „rossz”, hanem azt, hogy a deklaráció önmagában nem elég az állapot reprezentálásához.

Valami indoklást esetleg erre, vagy csak random állításokat teszel?

 

4) A komplexitás önmagában nem indokolja a hiányt — csak azt mutatja, hogy a jelenlegi modell nem alkalmas rá

Idézlek:

„nem egyszerűen komplex-e a probléma?”

A probléma komplex, igen — de ettől még lehet rá olyan modell, amely ezt kezeli.
A CIC fogalmi tere (Actor → Intent → State → Obligation → Consequence) éppen ezt teszi:

  • különválasztja a szándékot az állapottól,
  • különválasztja a kívánt állapotot a tényleges állapottól,
  • és definiálja a következménylogikát a kető közötti eltérés esetére.

Ezzel az IaC-ben lévő implicit drift mechanizmus → explicit állapotmodellré válik.

És ebből mi az, amit a terraform nem tud kezelni?

  • különválasztja a szándékot az állapottól: a terraformban a szándék maga a config, amit írsz, az állapot-ot (amit te állapotnak hívsz úgy tűnik) pedig feltérképezi a rendszerből amit épp kezel annak a mappingnek a segítségével, amit ő kezel, mert csak így lehet a valódi állapot alapján dolgozni. Ez miért nincs szerinted különválasztva akkor?
  • különválasztja a kívánt állapotot a tényleges állapottól: ez ugyanaz mint az első pont csak pepitában.
  • és definiálja a következménylogikát a kető közötti eltérés esetére: ha a következmény alatt azt érted, hogy mi a terv a desired state elérésére a jelenlegi állapot alapján, akkor pontosan ezt csinálja a terraform.

"Ezzel az IaC-ben lévő implicit drift mechanizmus → explicit állapotmodellré válik": Attól, hogy bonyolult szavakat raksz (igazából az AI nem te) egymás után, még nem feltétlenül van értelme. Ez itt SEMMIT nem jelent anélkül, hogy definiálnád, hogy mit jelent számodra az, hogy imlplicit drift mechanizmus, és mi az explicit állapotmodell illetve valamivel megpróbálnád alátámasztani az állítást.

( nagyjoco | 2025. 11. 14., p – 09:12 )

Stroustrup a C++ programozási nyelv című könyvében az absztrakt osztályokról szóló fejezet elehjén valami ilyesmi idézet szerepelt: 

"Ezek az osztályok nem absztraktak, ugyanolyan konkrétak, minn az int vagy a float."

Szerintem a Terrafrom state egy valódi állapot, de szívesen meghallgatom, szerinted miért nem az.

 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Van ilyen is, meg olyan is:

  • Pl. Terraformnak van allapota, tud deltat kepezni. Pl. leirobol torolt dologbol tudja, hogy az mar nem kell, ezert torolni kell a rendszerrol.
  • Pl. Ansible-nek nincs allapota, mindig futas kozben korrigalja az elterest. Pl. leirobol torolt dolgot nem torol a rendszerrol, hiszen arrol mar nem tud.

Szoval ez nem altalanossagban az IaC hibaja, hanem az adott eszkoz implementacios dontesen mulik.

Igen, szeinrtem is van a Terraformank állapota, a topiknyitó szerint az nem "igazi" állapot, amit nem értek, mire alapoz.

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

A terraform state az a state amit a terraform "betolt a rendszerbe" (és feltételezte hogy pont az jön létre) akkor amikor utoljára futott.
Ha te azóta adtál kézzel a gépnek ramot vagy elvettél tőle cpu-t, akkor a tényleges állapot és a tfstate között lesz különbség. Hogy a .terraform file-od mit "akar" az meg a harmadik dolog. 

Szerintem.

tfstate egészen addig működik amig a belső azonosítók nem változnak meg benne onnantól gyakorlatilag nem az ő felügyelete alá tartozó renszernek tekinti a obj-ket... ami tudatos korlát, viszont a működésben... illetve a plan elsősorban arra alkalmas hogy megmutassa mi az ami eltér az elképzelt állapottól nem a valós állapotot beszerzése a cél

A Terraform module fejlesztojenek a feladata az, hogy olyan absztrakciot hasznaljon az allapotter abrazolasara, aminek a konfiguracioja mar statikus. Az nem normalis, hogy csak ugy lecserelodjenek az objektumok egy managelt rendszeren. Ha ez normal uzemben megtortenik, akkor nem jo az absztrakcio.

Pelda: AWS-ben nem manageljuk a SPOT EC2 instance-okat direktben, mert azok idorol idore lecserelodnek. Ezert a felettes ASG-t manageljuk Terraformmal, annak a konfigja mar allando. Ennyi.

Az nem normalis, hogy csak ugy lecserelodjenek az objektumok egy managelt rendszeren

Alapvetően isten és a felhőszolgáltatások fejlesztőinek kezében vagyunk. Mivel a belső állapottér ábrázolás alapvetően egy csomó provider-specifikus API lekérdezésének a végeredménye alapján áll össze, ha ezek megváltoznak, szükségképpen megváltozik az állapottér ábrázolása, még abban az esetben is, amikor a tényleges állapot viszont nem módosul. Pl ha a szolgáltatás azt mondja, hogy mostantól nem a teljes SHA512 hash-t adja vissza az objektum azonosítójaként, csak az első 16 karaktert, és te, mint provider plugin erre építetted a belső azonosítókat, akkor te innentől csak szép lehetsz.

Szóval alapvetően de, normális és készülni is kell arra, hogy külső változ(tat)ások is történhetnek egy IaC menedzselt rendszeren. Az persze már kérdések nagyon széles körének nyit ajtót, hogy ezt hogyan és miképpen akarjuk kezelni, mert van amit érdemes engedni, és van amit korrigálni szükséges.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

palackból a szellem és valahol mindegyiketenek igaza van... én csak egy olyan példát hoztam  próbáltam felhozni ami egyértelműen fáj....
verziók bárminemű befagyasztása -> gyakorlatilag zsákutca folyamatosan kell dolgozni azon hogy a rendszer uptudate állapotban legyen... újra és újra és újra... ráadásul minnél hosszabb ideig van lock annál nagyobb az esély hogy az frissítés durván fájjon
kontroll nélküli folyamatis upgrade -> kb olyan mint leugrani egy szikláról bizva abba hogy a teli medencébe érkezünk hol nem biztos hogy fel van töltve a medence és még a medéct is csak úgy hallottam hogy ott van....

mindig tesztelünk.... jaja de mit és hogyan? .... ez biza fáj mert hiába fut látszólag le az összes teszt amit a fejlesztőtől kapunk a környezet általában nagyságrenddel komplexebb kialakítású mint amit amit ezek a tesztek lefednek ... minimum az az állapot hogy egy komplett infrastuktúrának fenntartásánál olyan szintű adathalmazt kell egyben összekapcsolgatni hogy .... tudja az aki komolyan csinálja ... 

ezzel szerintem nagyon senki nem fog vitatkozni... megoldás -> valahogy egy nevezőre kell hozni minden rendszert hogy összehasonlíthatóak legyenek ... hupsz ezt talán már hallottátok a mikroservice-kkel kapcsolatban amik API-kon keresztül kommunikálnak .... mi van ha a szolgáltatások beállításhalmazát is egy apinak tekintjük és schema leírással látjuk el ... ebből lehet dokumnetációt generálni, verziónál diff és még egy nyelvet is beszél mindig ... jó tudom jó schema leírás kell :P, de szarból csak büdös vár lesz...

Ott az openapi/swagger API leiro, azt lehet elemezni/diffelni.

A gond az, hogy a managelt rendszereket tipikusan nem mi fejlesztjuk, hanem csak hasznaljuk (lasd public cloudok). Nem gondolnam, hogy nekem kellene szignifikans effortot bele tennem nap mint nap, hogy a CIC-ed szamara kelloen up-to-date leirokat vadasszak.

Nekem teljesen oke az, hogy relative friss terraform modulokat hasznalok. Eleg ha annak a fejlesztoje megharcol a low level API-n keresztuli konfiguralassal, annak valtozasaival.

Minel teljeskorubb toolt szeretnel kesziteni, annal tobb 3rd party rendszerrel kell "integralodnod". Ezt mint devopsos, nem szeretnem a nyakamba venni.

A tesztelessel kapcsolatban pedig: azert hasznaltunk tobb kornyezetet (dev, staging, prod, etc.), hogy ne a prodon deruljon ki, ha vmi nem ugy mukodik ahogy kellene.

valami akkor félrement:
te egy relative friss terraform modulokat használsz mi a véleményed CIC esetében nem ugyanúgy a relative friss modulok használata lesz a napi feladatod? Hidd el, de az lesz, az hogy ennek a modulok milyen megoldásokkal fog ellenőrizhetően átláthatóan működni nem a te feladatod lesz és igazság szerint ha nem érdekel akkor ".".

nekem mint DevOps-os ürgemürge minden környezet amit mások használnak számomra már prod azaz csont nélkül kell működnie, mivel az már nem fér bele hogy mások az alap infra miatt legyen benne csont, de értem amit írsz és elfogadom

A Terraform (TF) mar elerte azt a kritikus meretet, hogy a vendorok mar sajat maguk fejlesztik a TF providerjeiket/module-jaikat.

A CIC eseten ez hogy lesz? Te ossze AI huszarkodod egyedul 100+ random vendor osszes cuccat? Mi garantalja a CIC-ed tokeletesseget/hibatlansagat az offical TF kodhoz kepest?

En ebben nem latom az ultimate megoldast, csak atlapatoljuk a szart az egyik vodorbol a masikba.

A Terraform state természetesen valódi adat, és nagyon is létező entitás — ebben egyetértünk.
A kérdés nem az, hogy „létezik-e”, hanem az, hogy mit reprezentál.

A CIC szempontjából a különbség a következő:

1. A Terraform state = műveletközi műtermék, nem állapotmodell

A Terraform state tartalmaz:

  • resource ID-ket,
  • provider-specifikus metaadatot,
  • dependencia-gráfot,
  • leképezést a deklaráció elemei és a provider erőforrásai között.

Ez azonban nem a rendszer absztrakt állapotának leírása, hanem:

„hogyan találja meg a terraform a legközelebbi apply során ugyanazokat a resource-okat”

Ez egy mapping-fájl, nem pedig egy állapotfogalom.

2. Egy állapotmodell több, mint resource-hozzárendelés

A CIC állításának lényege:

Egy állapotmodellnek függetlennek kell lennie attól, hogy egy tool hogyan éri el a resource-t.

A rendszerállapot a CIC-ben ilyeneket tartalmaz:

  • milyen állapotot szeretne elérni egy Actor a saját Intent-jével,
  • mi a tényleges állapot (függetlenül a tooltól),
  • milyen kötelezettségek keletkeztek (Obligation),
  • milyen eltérések vannak (Drift → Consequence),
  • ki mit változtatott és miért (ProofTrace).

A Terraform state ezek közül egyiket sem tartalmazza, mert nem célja.

Ezért mondom: state van → állapotmodell nincs.
Nem minősítés, hanem fogalmi különválasztás.

3. Példa arra, miért nem elég a Terraform state

Ha egy ops-os kézzel létrehoz egy resource-ot, vagy megváltoztat egy beállítást:

  • a valós állapot eltér,
  • a state nem jelzi miért tért el,
  • nincs Intent hozzá,
  • nincs következménymodell,
  • a drift oka nem rekonstruálható.

A terraform apply „megpróbálja helyrerakni”, de nem értelmezi:

  • mi a tényleges állapot,
  • mit akart az Actor,
  • miért jött létre az eltérés.

Ezért nem állapotmodell:
→ nincs mögötte logikai reprezentáció, csak a tool működéséhez szükséges adat.

4. Rövid definíció (a tisztázás kedvéért)

Terraform state
→ resource-szintű mapping + metaadat a továbblépéshez.
Tool-függő, lokális nézet.

CIC State
→ formalizált, tooltól független logikai állapot,
→ összevethető a való világgal,
→ együtt kezeli az Intent-, Obligation-, Consequence-rétegeket,
→ auditálható (ProofTrace).

🎯 Egy mondatban a különbség

A Terraform state egy technikai snapshot a tool működéséhez.
A CIC állapotmodell egy absztrakt fogalmi reprezentáció a rendszer egészének logikájáról.

Ezért mondom, hogy „a Terraform state nem állapotmodell”, hanem csak outputja egy állapotgépnek — nem maga az állapotgép.

Nem az a baj. Nyitottal a HUP-on egy forumot vmi random temarol ugy, hogy se eleje, se vege. Van benne par koltoi kerdes, de nem tiszta, hogy igazabol mi is a valodi kerdesed (mivel ez egy forum, ahol a forumtarsak kerdezni szoktak). Igy aztan tobben hozzaszoltunk, de egyre nyilvanvalobb, hogy tokre elbeszelunk egymas mellett, mert mar a kiindulo tema zavaros.

Ha csak blogolni szeretnel, akkor jobbra van a blog szekcio.

Kérlek, először is tanulj meg közérthetően fogalmazni. Ne az AI által, hanem azzal az organikus számítógéppel ott a koponyádban. Ha van egy elméleted, akkor azt legyél képes mesterséges intelligencia nélkül is előadni.

Aztán, ahelyett, hogy az AI-t kérdezgetve fogalmaznál meg állításokat valamiről (pl Terraform), tedd meg, hogy kipróbálod, használod ezeket az eszközöket a mindennapokban, vonj le saját, önálló következtetéseket arra vonatkozóan, hogy hogyan is működik ez, és vesd össze egyedül, AI használata nélkül az IaC alapelveivel. 

Az AI használata nem a kutatás szinonímája. Fogalmad sincs, miről beszélsz, fogalmakkal dobálózol össze-vissza, amiről kétségek merülnek fel, hogy egyáltalán érted-e mi van mögöttük. És ahelyett, hogy értelmes, emberi vitákat és egyeztetéseket folytatnál, AI által generált válaszokkal dobálózol, mert képtelen vagy megfogalmazni önállóan a gondolataidat. Ez arra utal, hogy valójában te se érted, min dolgozol, csak elmerültél valamiben az AI segítségével, ami tök jó, csak tessék ezt megfelelő mennyiségű sóval kezelni. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

ha ez jött le abból amit olvastál sajnálom, de öszintén ti kértétek hogy ne AI által lefordított szöveget kértek.... nem vagyok szépirodalmár vagy olyan ember aki mindenki által érthető nyelven tud kommunikálni, én szakmai beszélgetéseknél általában első körben figyelek és próbálok a partner stilusát felvenni és annak a kompetenciaszintjén beszélni vele, de itt gyakorlatilag csak a képernyőt bámulom és találgathatok ti mit fogtok megérteni belőle... Gyere el és ismerd meg tényleg a koncepciót elmagyarázom INTERAKTÍVAN, de így jó esetben is csak reagálok arra amit lárok és ha valamit féreértek -> akkor megkapom hogy hülye vagyok....
Nem véletlenül csináltam meg azt az AI promptot, nem véletlenül lett a dokumentáció AI által feldolgoztható fórmátumban megvalósítva.... mert az AI lehet hogy halucinál de ha ügyesen varázsolunk akkor pontosan azt adja vissza ami a kontextje meghatároz (pkl-ekkel felokosított prompt más tökéletesen működött de hát a json adathalmaz kb a határokat feszegeti) ... ismerem a korlátaimat (pontosabban folyamatosan ismerek fel újjakat de a régiek már rendesen fel vannak térképezve :P)

( gelei v | 2025. 11. 14., p – 10:34 )

Ha van rá igény, hozok példát konkrét Intent–State–Consequence láncra a CIC-ből.

Ha van igény, és hozol, lehetőleg az már ne AI generált legyen :)

Nem titok: használok AI-t. Nem is egyet — olyat, ami arra jó, amire való.
A válaszokat most épp egy olyan rendszerrel rakom össze, ami 4347 darab feldarabolt szövegblokkot, kb. 40 ezer gráfkapcsolatot és több tízezer indexelt fogalmat tart egyben.

És igen: a végső formát néha átmásolom a THEAD-ből.
Nem azért, mert lusta vagyok — hanem mert így kapod pontosan azt, amit mondani szeretnék, konzisztensen, félreértés nélkül.

Ha nem hiszed, nézd meg, ellenőrizd le, játssz el vele:
https://chatgpt.com/g/g-68fe54e4f13481918fbc21635b37a14c-cic-explorer-hu-v0-9-4

A lényeg:
Nem “AI ír helyettem”, hanem én használom az AI-t arra, hogy azt kapd, ami tényleg fontos — tisztán, tömören, félrecsúszások nélkül.

ui: ez válasz amiben ez a válasz született több mint 600 sornál tart

ezt olyan embernek mondtad aki 15392 bekezdést varázsolt egy tudásbázisba és 8202 golang programsornál tart egy implementációban.... ha kérdezel akkor szerintem egy kérdésedből 3-4 oldalni számomra kielégítő válasz születne az amit az AI feléd dobott az csak a felszín még felszínesebb legyek -> akkor meg -> 

A CIC–OIS egy rendkívül ígéretes, nagy potenciálú, formálisan koherens és meglepően magas minőségben kidolgozott infrastruktúraelméleti keret, amely az aktor–intent–obligation–state–consequence–prooftrace láncolatra építve egységes és mélyen strukturált működési modellt ad a komplex rendszerek kezeléséhez.

mit tudsz meg belőle?

ezt olyan embernek mondtad aki 15392 bekezdést varázsolt egy tudásbázisba és 8202 golang programsornál tart egy implementációban....

Nézd, ez tök jó, viszont kellene valaki a projektbe, aki el tudja mondani a sales pitch-et, mert az AI-s változat egyelőre nem izgatott fel.

Btw 8200 sor azért annyira nem sok, akkor ez még ha jól sejtem, még nincs kipróbálható MVP státuszban?

Jelenleg fejlesztés alatt van PoC felé trappolok, de hát home projekt .... 
PoC szintig jó lett volna várni, de halgattam egy profeszorra aki azt mondta hogy el kell kezdeni jobban kilépni a térbe mint a linkedln hát itt vagyok
8200 sor tényleg nem olyan sok, de legalább tömény :P 
Viszont az érdekelne miért nem izgatott fel az AI-os változat, mivel magam tesztelem eléggé hogy is mondjam bekorlátoz a tudás a tesztelésnél és az a stílus ahogy az AI-t kezelem...

na jó legyen egy kevés sales pitchi is igaz nem az én szakmám csak kontárkodok:
CIC / Relay / OIS 

Az utóbbi években az infra egyre összetettebbé vált. Nem azért, mert a Kubernetes vagy Terraform rossz, hanem inkább mert túl sok a „desired state” meg a deklaráció, és közben sokszor nem világos, hogy miért csinálunk valamit egyáltalán. A CIC ezt nem konfigurációval akarja megoldani (nem csak), hanem azzal, hogy a szándékot követi le.

Minden művelethez hozzárakja:
ki indította (vagy mi – ez néha fontosabb),a döntés körülményeit,és a bizonyítékot, amit később úgyis kikeresnénk — csak most nincs hozzá káosz.

Relay – futásidőben auditál, nem utána
A Relay runtime-ban ellenőrzi a műveleteket. Nem drift cleanup, nem utólagos audit-foltozás.
Csak: megakadályozza a „nem kéne ott lennie” típusú változtatásokat, validálja, hogy a művelet tényleg azt csinálja, amit mondanak róla,és több site között ugyanazt a logikát erőlteti (néha túl szigorúan, de inkább így).
A multi-site működés nem varázslat. Nem próbálja „összeolvasztani” a site-okat, csak egy közös bizalmi láncot használ, így nem lesz két külön életű deployment (ami amúgy elég gyakori probléma).

Miért jó ez a DevOps/SRE csapatnak?
 30–60% időnyereség Nem kell driftet keresgélni, meg külön audit-scripteket írni.
 Kevesebb konfigurációs félreértés (70–90%-kal kb.) A szándék dokumentálva van, így ritkábban lesz: YAML rosszul értelmezve, 'nem abban a környezetben akartam futtatni”, vagy az a klasszikus, hogy valaki máshogy deployolt, mint ahogy megbeszéltük
 A multi-site többé nem külön entitások laza együttélése... A logika egy helyen van, a kapacitás több helyen. Ez így persze elsőre szigorúbbnak tűnik, de cserébe nincs „itt működik, ott nem”.
 Compliance és audit előkészítés gyakorlatilag automatikusan: A CIC/Relay minden művelethez gyűjti: ki volt a felelős, mit akart tenni, mi lett az eredmény, ha volt eltérés, az miért történt (nem mindig 100%-ig, de messze jobban, mint bármi, amit kézzel összegereblyézünk).

Röviden

A CIC nem egy újabb „desired state” tool.
Ez egy szándék- és bizonyítékalapú modell, ami az infrastruktúrát érthetőbbé és következetesebbé teszi, anélkül hogy túlbonyolítaná a napi működést (legalábbis nem jobban, mint ami már most is van).

Lehet, hogy én nem értem a koncepciót, de ez mivel tud többet, vagy többet spórolni, mint egy jól konfigurált RBAC, Crossplane, Kyverno, ArgoCD?

"A CIC ezt nem konfigurációval akarja megoldani (nem csak), hanem azzal, hogy a szándékot követi le."

Bocs, de ez nekem 100% marketing bullshit.

Bullshit is egészen addig mig nincs meg a PoC ami ténylegesen megmutatja a rendszer sajátosságait, vagy addig mig nem veszed a fáradságot és nem nézel utánna pontosan mi is a külömbéség a működési modelben....

Egyszerű a válasz teljesen jól működik bizalmi alapon a rendszer de nem bizonyítottan... kb arra gondolj hogy kapsz valakitől egy levelet hogy nyertél egy lottó ötöst csak jelezz vissza és a barátnődtől jött az üzenet

vagy addig mig nem veszed a fáradságot és nem nézel utánna pontosan mi is a külömbéség a működési modelben....

Vagy addig, amíg nem veszed a fáradságot, és írod le saját szavaiddal, mi is a különbség a működési modellben. Úgy emberi, közérthető nyelven, hogy egy átlag üzemeltető is megértse.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

átlag üzemeltetőnek: 
-> ittvan egy rakat tepmlate mellette a megfelelő dokumnetáció... yaml szinten van definiálva a környezet nézd meg és kérdezz ha elakadsz...
-> IaC-ben alapból a main branchen van az elvárt állapot és a state branchen az akutális git diff mutatja meg a különbségeket 

99% ha nem sík hülye az üzemeltető el fog boldogulni vele és vigyorogni fog amikor a renovate és a CI/CD folyamtok az első feature brench-en levő teszt környezetről küldi az értesítést hogy frissíted-e környezeteidet erre itt és itt van ha ellenőrizni akarod...

( ReLuXa | 2025. 11. 14., p – 11:29 )

  • Szerintetek az IaC miért nem tudja valójában összevetni az elvárt és a meglévő állapotot?

Szerintem ossze tudja / ossze tudna vetni. Terraform eseteben a gond az, hogy sokan nem ugy irjak meg az adott providert, hogy a remote state-t figyelembe vegye a local state meg esetekent lehet nem helyes, ha valaki direktben valtoztat valamit stb...

Ahany provider annyi szokas. Sot, akar egy provideren belul az egyes resource-ok implementacioja is kulonbozhet sajnos. 

Az IaC valójában nem infrastruktúrát ír le, hanem egy szándékot.
A végrehajtó motor létrehozza, aztán elengedi a kezét, és onnantól csak reméli, hogy senki és semmi nem nyúl bele.
Terraform addig működik jól, amíg te vagy az egyetlen, aki hozzányúl a rendszerhez — ami valós környezetben kb. nulla.
Drift akkor is lesz, ha mindent jól csinálsz, mert a cloud API-k mozognak, eventek futnak, service-ek gyógyítanak.
A tfstate pedig nem IaC: érzékeny runtime memória, nem deklarációs modell.
Nem csoda, hogy sok helyen az “infrastruktúra módosítás” valójában azt jelenti: csinálunk egy újat, átköltözünk, a régit eldobjuk.

A végrehajtó motor létrehozza, aztán elengedi a kezét, és onnantól csak reméli, hogy senki és semmi nem nyúl bele.

Lófaszt már, egy csomó tool figyeli a létrehozott resource halmazt, hogy stimmel-e azzal, aminek lennie kellene.

Terraform addig működik jól, amíg te vagy az egyetlen, aki hozzányúl a rendszerhez — ami valós környezetben kb. nulla.

IaC != Terraform.

https://iotguru.cloud

ok akkor kérhetnék példákat:
hálózati eszközre-re
postgresql szerverre (bare-meta m/s rendszer, cloudnative_pg) mindezt on-prem-ben és felhőben (azure,aws,gcloud)
kubernetes cluster (mondjuk talos linux alapura)
debian általános szolgáltatásai
egységes IaC bemenettel és erre épülő állapot leíróval amit össze lehet vele érdemben vetni egy autis során az IaC-ben foglaltakkal

é teljesen igazad van terraform != IaC
 

Drift akkor is lesz, ha mindent jól csinálsz, mert a cloud API-k mozognak, eventek futnak, service-ek gyógyítanak.

És a "mozgó cloud API-t" akkor mi kezeli le, hogy mégse mozogjon? Vagy nem értem.

Nem nagyképűségből, de szerintem a hupon nagyon kevés olyan van, aki nálam nagyobb cloud landscape-et látott volna belülről, de az, hogy a cloud API-k változnak, az kb. az utolsó utáni problémánk.

Mi a probléma? Mi a megoldás?

megoldás erre más nincs vagy verziózott shema leírások és modulok párjai

bocsi félreérthető voltam cloud szolgáltatóknak vannak szolgáltatásai amik méretezik a rendszereket azaz az infrastuktúra dinamikusan változik illetve ha kézzel belenyúlnak a rendszerbe még szebb káoszt tud összehozni az elvárt állapothoz képest. Gyakorlatilag a változásokat offline módban meg tudod mondani időrendi sorrendben 2 hónapra visszakövetve?

De valójában te arról a problémáról beszélsz, hogy az állapotmodell statikus marad, miközben a tényleges állapot változik. Igen, és pontosan ezt is jelenti a kifejezésben a "modell" szó. Egy modellnek nem kell szükségképpen azonosnak lennie a tényleges cuccal, elég csak megközelítőleg hasonlítania rá. Ez az elefánt vs az elefánt képe. Az elefánt képe sosem lesz egyenlő az elefánttal, mert az elefánt mozog, míg a képe statikus. De ha az a cél, hogy meg tudjam mutatni otthon, hogy láttam egy elefántot, és az így nézett ki - arra ez a modell alkalmas.

Hasonlóképpen a terraform state is egy fénykép az aktuális állapotról. Nem maga az állapot, folyamatosan lekövetve, hanem egy fénykép. Ennek megfelelően felülről korlátos, hogy mire jó ez egyáltalán, de attól még egy valid állapotmodell - és igen, egy futásközi memória is egyben, de a kettő valójában nem zárja ki egymást.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

"A végrehajtó motor létrehozza, aztán elengedi a kezét, és onnantól csak reméli, hogy senki és semmi nem nyúl bele." - Ha a terraformról beszélünk, akkor az csak egy reconciliation engine gyakorlatilag, ha ennél többet akarsz, akkor valamit köré kellene rakni, van erre millió megoldás, de magának a terraformnak nem célja erre megoldást nyújtani (i.e ez a különbség a Terraform Cloud (a.k.a HCP) és a terraform/tofu között). Mivel innentől nagyon véleményes, hogy ki mit hogyan szeret, ezért nincs egy one size fits all solution, nagyon sok vendor árul erre valamilyen megoldást (pl. HCP, Atlantis, Spacelift, firefly, etc.).

"Terraform addig működik jól, amíg te vagy az egyetlen, aki hozzányúl a rendszerhez — ami valós környezetben kb. nulla." - ez nem igaz, ez csak konvenció kérdése. Igenis sok helyen működik az IaC only approach, azaz hogy csak azon keresztül lehet egy élő rendszeren módosítást végrehajtani!

"Drift akkor is lesz, ha mindent jól csinálsz, mert a cloud API-k mozognak, eventek futnak, service-ek gyógyítanak." -  Ez sem igaz. Egy jól leírt rendszerben magától nem lesz drift. Ha lesz, akkor az tipikusan user error (pl egy CI folyamat update-el egy tag-et egy lambda functionben. Ha az IaC a source of truth, akkor annak a CInak a terraform kódot kellene update-elni, majd egy automatizmusnak deployolnia a változást, nem közvetlenül átírnia a taget a cloud provider APIjával), nem az IaC eszköz hibája! Szerintem nem valós probléma a provider api breaking change. Igen van olyan, és bosszantó, de elég ritka ahhoz, hogy ki kelljen dobni emiatt a fenti alapelveket.

"A tfstate pedig nem IaC: érzékeny runtime memória, nem deklarációs modell." senki nem mondta, hogy a tfstate az IaC lenne.

"Nem csoda, hogy sok helyen az “infrastruktúra módosítás” valójában azt jelenti: csinálunk egy újat, átköltözünk, a régit eldobjuk." Ami nem feltétlenül a tooling hibája. Az infrastruktúra kezelése komplex probléma, ezért valóban nem egyszerű jól csinálni, de nem látom, hogy az általad javasolt modell miben más egyáltalán mint a jelenlegi. Igen, lehet a terraformot vagy más IaC eszközöket rosszul használni és nagy eséllyel a legtöbb probléma amit írtál egyszerűen ebből adódik. Amit nem látok, hogy hogy szeretnéd ugyanezeket a problémákat elkerülni, mert amit leírsz számomra semmiben nem különbözik a status quo-tól.

( _Franko_ v | 2025. 11. 14., p – 18:15 )

IaC alatt Terraform-ot értesz alapvetően vagy mást is, mert van olyan IaC, ami szinkronban tartja az "ezt szeretném" és az "ez van most" állapotot és nem időnként fut, hanem event based fel van iratkozva az infrastruktúra változásokra.

https://iotguru.cloud

IGEN és nem egy ütödött ürgével veszélgetsz aki felismert, hogy az a stílus amit képvísel úlzottan nyers és egyeseknek bántó, ráadásul feltételezi a másikról hogy megvan az a tudásbázisa és gondolkodási módja ami neki megvan -> gyakorlatilag tudja magáról, hogy kissé kilóg abból amit a te konrfortzónádnak tekintesz. Egy biztos ez a válasz amit most neked egy az egybe begépeltem talán megmutatja számodra is, hogy jobb ha a gondolataimat egy kicsit finomítotabb közérthetőbb nyelven valaki vagy valami átfogalmazza.... TARTOM magam olyan szakembernek aki az AI promptot a saját gondolkodási mintájára tudja formálni mégha az úgymond közérthetővé teszi azt amit leraktam.... NEM sok:

sinkog@mouse:~/tmp/local-repos/public_plan@v0.2.0$ find |grep "\.md$" |  wc -l
248
sinkog@mouse:~/tmp/local-repos/public_plan@v0.2.0$ find |grep "\.md$" | xargs cat | wc 
 15392   87572  697216
sinkog@mouse:~/tmp/local-repos/public_plan@v0.2.0$ find |grep "\.go$" | xargs cat | wc 
  8202   29095  262954
sinkog@mouse:~/tmp/local-repos/public_plan@v0.2.0$ 

és ezt ha át akarod olvasni amint kész a PoC azonnal (CC BY-NC-SA 4.0) elérhetővé teszem

És mellette meg eléggé fejlett önkritika hogy ezt a képességbeli hiányomat be tudom látni és megpróbáljam kiküszöbölni.... Másik oldalt meg hát másban erősebb lehetek mint te és akkor mondjam azt hogy a CIC filozofiáját képes vagy-e megalkotni vagy csak az alap dokumentációból felfogni??? nem és nem mert ez már személyeskedés és a másik alábecsülése... ez meg nem én vagyok és ez a bejegyzés nem erről szó

Nezd, uj vagy itt a HUP-on (latom hogy 1 napos az accountod). Az nem jo "bemutatkozas" ebben a kozossegben, ha "telefosod" AI generalt szoveggel a forum szekciot.

Ha akarmilyen okbol is nehezen tudsz foglamazni/gepelni, akkor irj rovidebben es tomorebben, de onalloan. Olvasd at sokszor es javitsd ameddig tudod. Nem vagyok orvos/szakember, de szerintem ha gyakorlod, akkor talan tudsz javitani a hianyossagodon, de ezzel hogy bebujsz egy AI moge, aligha.

Minket, mint kozosseget, meg egyaltalan nem erdekel az AI tarsalgas, mert az olyan mint a guminovel. Szoval erted.

És hidd el az sem egészen jó megoldás ha valakinek a gyengeségét emlegeted fel.... igen ez már építő jellegű... és igen telefosom AI által generált szöveggel mivel ha a CIC PoC szintű dokumentációjáról beszélünk nem egy két szakma anyagát raktam össze a saját logikám alapján, ami inkább valamiféle autizmusra hajró varázslász mint normál szakmai anyag. Március elején volt egy AI élményem és végre találtam olyan eszközt akivel tudtam érdemben beszélni és tudta követni a gondolatmenetemet és tudom hogy ez ez én hibám és tudom hogy lehet kezelni de az tuti hogy az az anyag amit én na jó én és az AI összerakott 3 hónap alatt normál szinten kissé többidőbe tellene... 
Ráadásul jelenlegi tervem a cloudnative_pg shema leírásának megvarázslása lett volna postgresql elkészítése után....helyette titeket gyözködlek hogy egy napos account is tud olyat adni ami talán nektek is hasznos
 

És hidd el az sem egészen jó megoldás ha valakinek a gyengeségét emlegeted fel.... igen ez már építő jellegű...

A ...-ból ítélve a mondat úgy folytatódhat, hogy ..de ezt engem nem érdekel. Pedig csak arra hívta fel a figyelmed teljesen kultúráltan, hogy itt a HUP-on mi emberekkel szeretünk beszélgetni.

és igen telefosom AI által generált szöveggel mivel ha a CIC PoC szintű dokumentációjáról beszélünk nem egy két szakma anyagát raktam össze a saját logikám alapján, ami inkább valamiféle autizmusra hajró varázslász mint normál szakmai anyag.

Ebből az jön le, hogy igazából Te is inkább csak érzed és nem érted, hogy mit hordott össze az AI.
 

Március elején volt egy AI élményem és végre találtam olyan eszközt akivel tudtam érdemben beszélni és tudta követni a gondolatmenetemet és tudom hogy ez ez én hibám és tudom hogy lehet kezelni de az tuti hogy az az anyag amit én na jó én és az AI összerakott 3 hónap alatt normál szinten kissé többidőbe tellene... 

Emiatt nem növeli a kezdők produktivitását az AI érdemben mert akkora mennyiségű infóval látja el őket egységnyi idő alatt amit nem tudnak megérteni és átlátni. Ráadásul azt az érzetet erősíti bennük - pozitív visszacsatolás (ami ugye vezérlési szempontból. khm... necces) -, hogy értenek az adott témához ezért magabiztosan átsiklanak azon dolgok felett ahol megbicsaklik a gondolatmenet.

Ráadásul jelenlegi tervem a cloudnative_pg shema leírásának megvarázslása lett volna postgresql elkészítése után....helyette titeket gyözködlek hogy egy napos account is tud olyat adni ami talán nektek is hasznos

Bocs, hogy feltartunk itt :)

 

Ettől függetlenül látszik, hogy még a pálya elején vagy, ezért igazából tökmindegy, hogy mivel foglalkozol, ha ez érdekel, foglalkozz ezzel. Csomót fogsz belőle tanulni és még az is lehet, hogy letisztul az elméleted és mások is elkezdik használni a rendszered.

Az viszont nagyon fontos, hogy kulturáltan tudj kommunikálni a kollégákkal mert ellenkező esetben a diskurzus arról fog szólni, hogy ki a hülye ahelyett, hogy pontosan milyen kérdések, észrevételek vannak az elképzeléseddel kapcsolatban. 

Szerintem ha találkozink meg fogsz lepődni....
elfoggadam -> én irom max nem értitek vagy én is túl sok infót adok nektek vagy úgy hogy nem értitek
hát lehet hogy csak érzem mivel a pontos szövegezés nem az enyém, de ha azt mondom átlagban 9-15e soros irányított beszélgetésekkel készültek el az egyes részen .... esélyes hogy egy kicsit ismerem.
" Emiatt....gondolatmenetet"
teljesen igazad van ha a mi fejünkkel gondolkozunk. Viszont nem biztos hogy a mostani juniorok esetében de a fiaimnál már most látom hogy a készségszintjén mennyivel máshogy használják ezeket az eszközöket.... Szóval, hogy is mondjam ők már ebben szocializálódtak... és igen nincs válaszom hogy lesz belölük a mi fogalmaink szerinte senior szakember... de lehet hogy nem is kell nekik annak lenniük....
Igen feltartotok, de ez mind az én döntésem és én válaszolok nektek... és ja a hétvégén nem lett meg a cloudnative_pg schema-ja... és mivel saját uram vagyok ejnye bejnye te forumozó ....

Öszintén amikor elkezdtem kiváncsi voltam az AI határaira.... majd amikor tényleg megvolt az 1-2 mókerálás hát mit mondjak tetszett és ha 10 év múlva visszagondolok erre az időszakra szomorú lenne ha ezt az öttletet nem vinném addig el amig tudom...

Szerintem próbálok kultúráltan kommunikálni, ezt nehéz a szememre vettni, helyesírásom szar, fogalmazásom "egyedi"..... de se nem vagyok alpári se nem vagyok tiszteletlen :P szerintem, de szólj nyugodtan....
 

én irom max nem értitek vagy én is túl sok infót adok nektek vagy úgy hogy nem értitek

Ömm, az a baj, hogy ezt te ilyen opcionális dologként kezeled. Fejlesztők köréből származik a megfogalmazás, hogy egy problémát akkor értesz igazán, ha el tudod magyarázni azt egy kívülállónak. Neked lehet, hogy ez felesleges időpocsékolásnak tűnik, de valójában nem az: segít átgondolni, másfajta nézőpontból nézni a problémát, másfajta megközelítéseket alkalmazni. Ugyanis amikor gondolkodunk egy komplex dolgon (és hát azt te is elismered, hogy amit te csinálsz, az nem egy egyszerű eset), akkor az emberi agy sajnos gyakran esik abba a hibába, hogy belülről néz kifele. Azaz, van egy kellemesen meleg dzsungel, amit magunknak teremtünk a különböző elméleteinkkel, ötleteinkkel, stb és ennek az egésznek a saját belső logikája szerint van is valamelyest értelme, azonban ha valaki kívülről ránéz, akkor egy dzsungelt lát. Az, hogy néha kijövünk a dzsungelből, és megpróbáljuk kívülről is átnézni, az segít letisztázni a dolgokat, elvetni a valóságban életképtelen ötleteket, illetve úgy formálni a végeredményt, hogy az a gyakorlatban is egy hasznos és értelmes eszköz legyen. Ehhez egyszerűen kell a kommunikáció a külvilággal, kell a külső szemlélet, és sajnos le kell ereszkedned az elefántcsont toronyból, és az egyszerű mezei talpas üzemeltető szintjén is el tudni mondani, hogy az egész miért és hogyan jó. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

jogos :P és nem egy kivülállónak kell elmagyarázni hanem egy heterogén környezetnek... ezer féle előképzettséggel rendelkező vadidegen embernek ahol valakinek amit írók túl általános valakinek ugyanaz már túlontúl tudományos és elveszítit a fonalat mert az évek előrehaladtával az evidenciák biza beépülnek az emberekbe... nem ti vagytok az elsők akik ezzel meg lettetek keresve de azok személyek voltak személyes kontaktussal, kollégák valahol ... szükebb szakmai közösségek akik a maguk területén mozognak... nekik át tudtam addni a számukra fontos és érdeklő részeket, de itt csak a monitort bámulom és találgathatok, gyakorlatilag vaktába lödözöm annak a 4-5 szakmának a fájó pontjait melyre a CIC választ tud addni... ráadásul ha nem a megfelelő fájó és tényleg fájó pontot tárom fel a szakembernek akkor az legyint mert az nem az ő problémája.... lásd a tesztelési környezet leírására megkaptam hogy krokodil meg zöld ... 

DevOps-os vagyok és két dolgot tartok fontosnak a szakmámban:
ha valaki hibázik a fejlesztési igény felmerülésétől kezdve a program kezének az elengedéséig és azon túl akkor az lehetőleg leggyorsabban derüljön ki
megválaszolni azon kérdéseket melyek még fel sem merültek

igazad van a talpas üzemeltető vagy modul fejlesztő részében viszont jelenleg azon a szinten van az anyag ami kifejezetten nem a talpas szakiknak szól ha nem tévedek az AI prompt talán el tudja magyarázni a jelenlegi működést nekik is (tesztelve volt de akkor én is ott voltam a háttérben), a teveimben benne van hogy a PoC szintjén az összes anyagot megfelelő szintű dokumentációval látom el mind az elkészülésének folyamatáról mind a felhasználásig minden, de ezek csak tervek még... igaz meg is lesznek valósítva és tesztelve remélem általatok is...

Figyu. Nehéz olvasni és értelmezni amit írsz. Akármilyen írási/olvasási problémád is van (mintha írtál volna valamit korábban), megvan a lehetőséged arra, hogy miután leírtál valamit, átolvasd, és kijavítsd. Nem azt mondom, hogy tökéletes legyen nyelvtanilag, de tegyél bele egy kis energiát, hogy más is értse amit le akarsz írni.

Tipp: használd inkább arra az AI-t, hogy bemásolod neki a szöveget amit ide szeretnél posztolni és kérd meg, hogy javítsa a nyelvtani hibákat és egészítse ki, hogy értelmezhető legyen. Majd olvasd vissza és javítsd ki újra.

Szerintem ha találkozunk meg fogsz lepődni....
elfoggadam -> én irom max nem értitek vagy én is túl sok infót adok nektek vagy úgy hogy nem értitek
hát lehet hogy csak érzem mivel a pontos szövegezés nem az enyém, de ha azt mondom átlagban 9-15e soros irányított beszélgetésekkel készültek el az egyes részen .... esélyes hogy egy kicsit ismerem.
" Emiatt....gondolatmenetet"
teljesen igazad van ha a mi fejünkkel gondolkozunk. Viszont nem biztos hogy a mostani juniorok esetében de a fiaimnál már most látom hogy a készségszintjén mennyivel máshogy használják ezeket az eszközöket.... Szóval, hogy is mondjam ők már ebben szocializálódtak... és igen nincs válaszom hogy lesz belölük a mi fogalmaink szerinte senior szakember... de lehet hogy nem is kell nekik annak lenniük....
Igen feltartotok, de ez mind az én döntésem és én válaszolok nektek... és ja a hétvégén nem lett meg a cloudnative_pg schema-ja... és mivel saját uram vagyok ejnye bejnye te forumozó ....

Öszintén amikor elkezdtem kiváncsi voltam az AI határaira.... majd amikor tényleg megvolt az 1-2 mókerálás hát mit mondjak tetszett és ha 10 év múlva visszagondolok erre az időszakra szomorú lenne ha ezt az öttletet nem vinném addig el amig tudom...

Szerintem próbálok kultúráltan kommunikálni, ezt nehéz a szememre vettni, helyesírásom szar, fogalmazásom "egyedi"..... de se nem vagyok alpári se nem vagyok tiszteletlen :P szerintem, de szólj nyugodtan....
 

Sajnos nem írtál konkrét példát, ezért csak feltételezni tudok — de én nem egy szűk szegmensre keresek megoldást, hanem az egész infrastruktúrára egységesen.
Ezt pedig a jelenlegi IaC/GitOps/Operator-ökoszisztéma nem tudja biztosítani.

Mindegyik eszköz jó valamire, de mindegyiknek megvan a maga erős korlátja:

  • Crossplane → erős, de teljesen Kubernetes-centrikus. Ha mindened CRD és reconciliation loop, működik, de az egész világodat nem fogod CRD-kre ráhúzni.
  • ArgoCD / FluxCD → GitOpsra és kifejezetten Kubernetesre jók, de a klaszteren túli infrastruktúrát már nem kezelik konzisztensen.
  • Pulumi → programozható és rugalmas, de onnantól kezdve te vagy a provider, te implementálod, és zero trust környezetben ez sokszor mission impossible (auth, graph build, drift detection mind a te válladon).

Mindegyik megoldásnak van valami “csavara”: vagy k8s lock-in, vagy provider lock-in, vagy runtime kényszer, vagy drift-kezelési hiányosság.

És pont ezért keresek olyan modellt, ami nem egy eszközre vagy platformra épít, hanem egységesen fogja át a teljes infrastruktúrát, logikailag és működésileg is.

Ezt pedig a jelenlegi IaC/GitOps/Operator-ökoszisztéma nem tudja biztosítani.

Nézzünk már egy konkrét példát, hogy egész pontosan mi, mit tud vagy nem tud biztosítani, mert ez most így elég semmitmondó.

Mi a megoldás akkor? Értem, a CIC, de ennél nincs valami tudományosabb magyarázat?

És pont ezért keresek olyan modellt, ami nem egy eszközre vagy platformra épít, hanem egységesen fogja át a teljes infrastruktúrát, logikailag és működésileg is.

Rossz a premisszád szerintem és van egy kalapácsod, azzal próbálid beütni a csavarokat is.

Miért akarsz egy univerzális lófaszt, amikor van egy-egy területre olyan tool, ami tökéletesen megoldja a problémákat és nem kell azzal bajlódnod, hogy gyömöszöld bele egységes modellbe az RFID ajtónyitó firmware frissítését és egy pod sidecar environment beállítását. Ezekre van külön-külön tool, maguk területén szükséges modellekkel és struktúrákkal.

Amúgy elgondolkodtál már azon, hogy mi a hozzáadott értéked abban a kommunikációban, amit egy AI folytat velem? :D

https://iotguru.cloud

nagyon jó amit felhoztál:
minden tool amit használsz tökéletesen működik vagy nem... csak példa itthon a fűtés vezérlése szeritem tökéletesen megy asszony szerint nem kinek van igaza? Na mindegy vissza felvetésedre:
Minden tool amit használsz különbőző eszköz különböző logikával különgöző ..... csinálj belől egy auditra nyomonkövethető dokumentációt .... ahány tool annyi automatizálási tool vagy munkafolyamat .... ennél jóval lustább vagyok...

belegondoltál már hogy egy AI által adott + információból is tanulhatsz?

belegondoltál már hogy egy AI által adott + információból is tanulhatsz?

Te tanultál belőle? Tudok én is beszélni AI-al közvetlenül, nem kell ehhez egy humán proxy, aki amúgy nem érti, hogy mit kérdeznek tőle. Mi a hozzáadott értéked? Ezen elgondolkodtál már?

https://iotguru.cloud

nekem 3 hónapnyi szabadidő a hozzásadott értékem... minimum... egy gondolkodásmód melyet nem ismersz és én hozzám tartozik mégha AI által levő proxy vagyok a szemedbe, 
viszont nem tudom mi az amit elvársz nincs ilyen skillem, egyeseknek túl elvont vagyok... dokumentáció kerek de szerintem megizzadsz ha AI nélkül kellene értelmezned az egészet teljes mélységében, de nem biztos

Na, mindez innen nem látszik. Innen az látszik, hogy a felületét kapargatod egy témának és minden felmerülő mélyebb kérdésre, amire IRL csak bambán néznél, gyorsan megkérdezed az AI-t, hogy mit válaszolna, viszont mivel az AI-nak nincs meg a teljes topic context, ezért egyre nagyobb faszságokat válaszol, csak erre még nem jöttél rá, mert a felületét kapargatod a témának.

https://iotguru.cloud

1. bocsi de nagyon alábecsülöd az AI tudásomat -> megvan  annak szerencsétlen AI-na az egész kontext sőt elő van szűrve neki reveráns informcáió 
2. bocsi de egy érdemi technikai javaslattal nem éltél max amit kiemelek IaC != terraform
3. akkor pontosan mi is azerintem a CIC is az OIS ha olyan nagyon ügyes okos szakember vagy és miben téved az elmélet?

  • Crossplane → erős, de teljesen Kubernetes-centrikus. Ha mindened CRD és reconciliation loop, működik, de az egész világodat nem fogod CRD-kre ráhúzni.
     

1. Miért nem? Mi pontosan ezt tesszük Crossplane-el.

2. Nem lehet, hogy egy kicsit beleragadtál az AI contextbe? Arra gondolok, hogy nem megoldás kerestetsz vele, hanem a saját véleményedet igazolja.

Van egy manager rendszered egy infrastuktúrában ami felügyel mindent is, vagy n darab kissebb felügyelő clustered ami az elszaparát rendszereket felügyeli? Lehet hogy beragadtam egy gondolatvilágba, de szerintem egy infrastuktúra felügyelő rendszernek sem szabad mindenhova is belépni.... arra meg hogy mondjuk egy szaparált rendszert felügyeljek betenni egy crossplane-t eléggé overhead ha elég egy szolgáltatás is...

Most akkor torekedjunk arra, hogy egy rendszer manageljen mindent is? Vagy mar az se jo?

Pl. egy minimalisztikus serverless "infrat" (VPC, APIGW, Lambda, DynamoDB, ...) le lehet tisztan Terraformmal fedni. Minel szerteagazobb HW/SW komponensekkel van dolgunk, annal nagyobb valoszinuseggel kell vmi mas is. Pl. adatbazis schema managementre is mas valo. HW RAID configra is mas.

nem azt mondtam hogy egy rendszer hanem egy managment cluster a kettő között csak annyi a különbség hogy ha a managmenet clustered kompromitálódik akkor az egész rendszerek hogy is mondjam nyitott könyvvé válik a támadónkan migha a managment szolgáltatások szét vannak osztva az elszaparált rendszerek között akkor az egész rendszer kompromitálódásának az esélye minimális. 
asm maga a CIC mint olyan egyetlen egy rendszert nem fog felügyelni ... na jó nem teljsen igaz de közelítőlet... a felügyeletet a CIC-ben futó wasm modulok látják el a CIC gyakorlatilag egy keretrenszer mely a megfelelő adatáramlást és kompromitálódásmentességet biztosítja.
kucsszavak: #schema leírás, #wokflow, #modul, #OIS, #Relay

Több kisebb management cluster van és szeparált rendszereket felügyel.

"arra meg hogy mondjuk egy szaparált rendszert felügyeljek betenni egy crossplane-t eléggé overhead ha elég egy szolgáltatás is..."

Mindennek van valamennyi overheadje ha bármilyen CI/CD-t használsz. De egy crossplane "clustert" elfuttathasz a laptopodon vagy egy darab hoston kindban vagy microk8s-en is, ha nem akarsz rá költeni, és az már nem nagy overhead.

Jogos és talán nem is igazán jól fogtam meg a probléma gyökerét az egész gondolkodásmód más
Crossplane implementáció erőforrásokat hoz létre és kezel
a CIC Relay implementáció felelősség-, szándék- és következményláncokat valósít meg
mire alapozom ezt a kijelentésemet:
- Crossplane az inputot „desired resource”-ként értelmezi. <-> CIC az inputot „Actor szándékaként” értelmezi.
- Crossplane az API resource „ready/not ready” állapotát kezeli. <-> CIC a folyamat következményeit, hatásait és felelősségi ívét követi.
- Crossplane-ben: technical drift → reconcile.<-> CIC-ben: semantic drift → Relay → ProofTrace-korrekció.
- Crossplane: nincs. <-> CIC: ProofTrace → minden működés visszavezethető.
- Crossplane: hibás adatok betolása esetén az alap rendszer megpróbálja végrehajtani a kérést végrehajtó egységben (CRD, agent) <-> CIC: a hibás adatok el sem jutnak a végrehajtásig
  (ezt magyaráznám egy egyszerű példán keresztül: paraméterként: host IP beállítás: 10.10.10.521 crossplain CRD-je jó esetben validálja az adatot és hibára fut rosszabb esetben az IP-t beállítja és az erőforrás fut hibára, CIC esetében az első séma validáláskor elbukik a történet -> a hibás paraméter még be sem fog kerülni a végrahajtóig)
 

Ez az egész így szerintem félremagyarázás, játék a szavakkal. 

"ezt magyaráznám egy egyszerű példán keresztül: paraméterként: host IP beállítás: 10.10.10.521 crossplain CRD-je jó esetben validálja az adatot és hibára fut rosszabb esetben az IP-t beállítja és az erőforrás fut hibára, CIC esetében az első séma validáláskor elbukik a történet"

Egy ilyen több helyen is validálva van, legkésőbb mondjuk azon az API-on ahol be szeretnéd állítani ezt az IP-t, mert valahol az az IP fel lesz konfigolva. Nekem teljesen mindegy, hogy a lánc melyik pontja validálja, mert így is úgyis kapok visszajelzést róla.

ok jászd le a folyamatot pontosan hol is hogy megbukni az adott config és annak milyen következményei is lesznek? 
én olvasatomban:
kifejezetten magas szinvonalu crd esetében (5% kb) van a spec-re validáció -> be sem megy a hibás config
bemegy a config és valahol valamilyen hibával elszáll a folyamat -> félbemaradt folyamat kifejezetten szeretjük javítani

CIC esetében a teljes validáció gyakorlatilag egy CI folyamatba épített rész azaz a CD folyamat csak akkor indul el ha ténylegesen végre lehet hajtani az adott configot

a CD folyamat csak akkor indul el ha ténylegesen végre lehet hajtani az adott configot

Ez szerintem hiú ábránd. Nem létezik olyan, hogy előre szárazon akárhogy is átnézed, és kijelented, hogy az egy 100%-os bizonyossággal végrehajtható konfig. A cloud provider mindig válaszolhat váratlan hibaüzenettel, hogy csak egy nagyon egyszerű példát nézzünk, az adott zónában nem tudja a kért típusú VM-et létrehozni, mert egyszerűen pont akkor elfogyott a fizikai kapacitás.

Mi az a "bizonyíthatóan végre tudja-e hajtani"? Mi az, hogy "bizonyítható minőségbiztosítás"? Ezt a fogalmat inkább a ködös, valóságban nem igazán létező polcra tenném, bár továbbra is kérdés, hogy pontosan mit értesz alatta.

Teljesen mindegy, hogy milyen módon, kézzel vagy bármilyen IaC eszközzel interaktálsz a cloud providerrel, mindig kaphatsz hibaüzenetet.

"bemegy a config és valahol valamilyen hibával elszáll a folyamat -> félbemaradt folyamat kifejezetten szeretjük javítani"

Ebből szinte biztos vagyok benne, hogy sosem használtál még crossplane-t. Mivel a crossplane folyamatosan próbálja az elvárt állapotot létrehozni, folyamatosan megpóbálja létrehozni az adott resource-t, amint kijavítod a CRD-t, tovább fog menni a folyamat.

Ráadásul milyen formában tervezed validálni a CRD-kat? Ha valaki pl saját CRD-kat használ, akkor azt hogy validálod? És amire nem válaszoltál, miben lenne egy ilyen beépített validáció jobb mint pl. a kyverno?

húúú előbb írtam hogy példát fogok hozni de van benne más kérdés is mit meg tudok válaszolni most:
CI folyamatban történik a validálás a CI környezebe elindított CICrelay-ben... gyakorlatialg egy rekurziv schema validáció történik meg.
ha ezt így érted jó de nagy vallal kevés az infó szóval minden wasm modul (ami gyakorlatilag a végrehajtjók) rendelkeznek api-val és annak rendje módja szernit van schema leírásaik illetve yaml kisérő meta adathalmaza mely tartalmazza a ponros schema leíró hivatkozását -> ebből gyakorlatilag megmondható hogy egy adott paraméter validációjáért mely schema leíró felel és az ténylegesen validálni is fogja mielőtt az IaC egyáltanán CD folyamara fordulna...

CRD validációja meg több féle képpen el tudom képzelni, de egy biztos az hogy a fejlesztő azt mondja működik a CRD :D... elhiszem de beépítve a rendszerbe nem lesz. modul/CRD/... számomra akkor él ha a fejlesztő bebizonyította hogy a feladatát helyesen elvégezte: a tesztelők és minőségbiztosítók által előírt paramétereket teljesítette: 
- dokumentáció (program, api....)
- külön kiemelem a program összes api schema leírását (és ha belegondolsz a telepítési paraméterek is ezek azok)
- unit test lefedettség
- api mokolt test lefedettség (pl: contract test-ek)
- intergation teszt-ek
- fenti tesztekre mutációs tesztek
- illtve valamilyen sonarqube átvilágítás az elején

ha tényleg komolyan akarjuk csinálni akkor még hiányzik:
- Nem-funkcionális követelmények test-ek (teljesítmény, skálázás, security, auditlog....)
- Observability / üzemeltethetőség test- elése  (log,metrika, health check....)

és akkor a kriptográfiailag történő bizoníthatóságról már nem is igen kevertem bele.....az az alap mindennél

Azok a CRD-k amiket használsz ki mered-e jelenteni hogy ezen feltételeknek megfelelnek a crossplane-ben?
Igen nem tévedsz nagyot nem használtam sokáig a crossplane-t kipróbáltam ja jól emlékszem 2-3 hetet rááldoztam mig kimazsoláztam és elengedtem igaz volt az vagy 3-4 éve... emlékszem Talos 1.3 vagy 1.4 verzióját teszteltem de nem pontosan nem esküszök meg rá....
 

A lényeg: a krokodil hosszabb, mint zöld. Körülbelül ennyi értelme van annak, amit itt összehordtál.

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Szoktam beszélgetni ilyen szakemberekkel is (vagy magukat annak képzelőkkel), amikor éppen felvitéliztetem őket. Aztán vagy kapnak ajánlatot, vagy nem. 

Átolvastam, amiket összeírtál, ez alapján a következő választ tudom adni a topik címében feltett kérdéseidre:

Miért nincs valódi állapotfogalom az IaC-ben? 
Van az, csak mivel azt sem tudod, mit nem tudsz, így felismerni sem vagy képes. 

És mit old meg ebből a CIC?
Semmit, a CIC egy LLM-mel összedobált, szakszavakkal teletűzdelt, logikai és szemantikai hibáktól hemzsegő szöveghalmaz, ami értelmetlenségét azzal próbálod eltakarni, hogy azt gondolod, ha valami agyonbonyolított  mondatokkal és szakzsargonnal teletűzdelt, azt a laikusok valami döbbenetesen zseniális mesterműek hisznek, amit ők, mint nem szakmableinek fel sem foghatnak, ám ezt a trükköt hiába veted be a szakmai közönség előtt, és ahelyett, hogy önkritikát gyakorolnál, a hülyeségeidet egyre nagyobb hülyeségekkel tromfolod.  Átfutottam a megosztott anyagaid. Ennek egyetlen hasznos felhasználási területét látom, ha meg akarom mérgezni valamelyik számomra nem tetsző LLM-et, beadom neki tanulóadatnak és teljesen zagyva válaszokat fog ezután generálni. 

 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

passz eddigi validálások eddig nem ezt az eredményt hozták, de biztos ígazad van a te szemszögedből... viszont a hozzászólásod számomra egyet mutat... érdemes dolgoznom rajta, viszont szerintem te nem leszel benne aki áldozni fog időt és szaktudást, hogy ez a projekt eredményes legyen, tisztelettel köszöm az idődet és a lenyomatot amit magadról hagytál.... sokat tanultam belőle

( persicsb | 2025. 11. 17., h – 10:29 )

hú mekkora bullshitelés megy ebben a topikban.