Ja, hallo, es ist zwei Uhr. Ich hoffe, ihr habt alle euer Mittagessen und die tolle Keynote von Molli überstanden und genossen, insbesondere. Und jetzt habt ihr es mit mir zu tun, tut mir leid. Die nächste dreiviertel Stunde ungefähr werde ich über

Formen und Catello reden, und zwar wie man es am besten automatisiert, und zwar mit Ansible, weil Ansible ist cool. Kurz etwas zu mir. Ich bin Evgeny, ich arbeite aktuell als Software Engineer bei Red Hat, habe vorher viel Consulting gemacht

bei der Red Hat, bin auch Debian und Grimmel-Developer, und ich hasse es, Sachen zweimal zu machen, deswegen liebe ich Automatisierung. Es ist einfach so, dass wenn man Sachen zweimal macht, beim zweiten Klick verklickt man sich auf jeden Fall, und naja, dann hat man irgendwo irgendwie einen Fehler eingebaut.

Das will ich nicht, und deswegen möchte ich alles, was ich irgendwie anfasse, automatisieren. Kurze Agenda, wie gesagt, kurze Motivation, WTF am Anfang, warum, wieso und überhaupt. Dann werde ich euch

erzählen, was es alles gibt, was ich nicht nutze, weil man muss ja irgendwie sich abgrenzen können. Dann stelle ich euch die Formen Ansible Modules, das ist das woran ich arbeite und was ich auch benutzte tagtäglich. Ich werde euch auch zeigen, wie man damit arbeitet, wie man bestimmte Workflows, die ich und Kollegen oft machen, abbildet.

Und das letzte ist, weil wir ja alle gute Open Source-Citizens sind, wie Mollis vorhin sagte, Contribution. Und Contribution ist für mich, für mein explizites Projekt, was ich euch heute zeige, die Module schreiben oder

Module erweitern, die wir haben, weil nobody is perfect und es gibt noch viele viele Baustellen bei uns. Motivation, ich nenne diese Folien auch gerne WTF, weil Motivation ist schwierig zu sagen.

Erstmal, was ist eigentlich Formen? Ich sehe eine Person mit einem Formen Installer-T-Shirt, super, sie hört mich nicht zu, aber nicht an. Wer sonst hier in der Runde kennt Formen und benutzt Formen?

Nicht ganz eine Hälfte. Gut, Formen ist ein Tool, eine Web-Uberfläche könnte man sagen und ein paar drunterliegende Software-Pieces, die dazu dienen, Server zu verwalten.

Und zwar Server jeglicher Natur, sei es Bare Metal bei euch irgendwie, im Data Center, sei es irgendwelche Virtual-Maschinen auf Ref, auf VMware oder auch gleichbehandelt irgendwelche Cloud-Instanzen, OpenStack, Google, Azure, whatever.

Es gibt auch ein bisschen Container-Support, aber irgendwie hat sich das nie so richtig verheiratet, weil Container sind zu kurzlebig für das, was Formen eigentlich macht. Und eine der wirklich geilsten Sachen an Formen finde ich, ist, dass es durch Plugins erweitert ist.

Das ist auch ein großer Pen-Punkt im Projekt, weil Plugins sind schwierig zu maintainen und immer gleich zu ziehen mit dem Hauptprojekt. Nichtsdestotrotz sind Plugins sehr wichtig. Ein paar bekannte Plugins sind zum Beispiel Catello, das Ansible-Plugin und das Monitoring-Plugin, um eben unterschiedliche Workflows aufzubilden, die Formen selber nicht kennt.

Ein so ein Workflow ist der, mit dem ich tagtäglich zu tun habe, das ist Catello. Das ist ein Plugin für Content-Management. Und zwar Content-Management im recht weit gefassten Sinne, solange es eben um Content für Server geht oder für Computer geht.

Es kann mit LPMs umgehen, es kann mit Debian-Paketen umgehen, gleichzeitig aber auch mit Container-Images, mit Puppet-Modulen. Oder eben ganz stur Files, weil irgendwo muss dieses komische Shell-Script dann doch rumlegen, was man wgetten so will.

Es ist deswegen so cool, weil dieser Content, der kann gruppiert und gefiltert werden, um jedem Server oder jedem Servertyp eigentlich, weil jeden einzelnen Server möchte man ja nicht herauskristallisieren, eine eigene Sicht auf die Welt zu geben.

Zum Beispiel Test-Systeme kriegen ein neueres Patchset als Produktionssysteme, weil Prod erst am Wochenende gepatcht wird oder sowas. Oder eben der normale Web-Server sieht gar keine MySQL-Libraries, weil braucht er nicht.

Und was er nicht installieren kann, kann er nicht verrotten. Und verrottene Systeme wollen wir eigentlich nicht haben bei uns. Und wenn wir Content schon irgendwie gruppieren und unterschiedliche Systeme zur Verfügung stellen können, können wir auch Snapshots davon erstellen,

sprich wir können zu so einem Snapshot auch zurückfahren und sagen, wir haben das jetzt mit der Version 10.2 von Software X ausprobiert, war jetzt aber nichts, wir rollen auf 10.1 zurück, ist ein Klick in der Oberfläche oder eben auf der API und es läuft.

Ein Punkt, den ich vorhin bei den Content vergessen habe, ist, da steht nur Puppet. Bald gibt es auch Ansible-Support. Ich glaube so, die sind am Arbeiten. Ich glaube in der aktuellen Version, die bald released werden soll, ist es noch nicht wirklich funktional.

Aber in der Version da drauf, also in drei bis vier Monaten, müsste es Support für Ansible-Collections geben. Und damit könnte man eben auch, ich könnte jetzt sagen, grob lokales Galaxy laufen lassen, um eben Content an seine Maschinen zu führen.

Das zu Formen und Ansible, Formen und Catello. Ansible ist das nächste Puzzlestück in meinem Talk. Ich mag dieses Zitat von deren Website, Radical Simple IT Automation Engine.

Es steht da insbesondere nicht drin, dass es ein Konfigurationsmanagement-System ist und jeder, der sagt, Ansible ist eins, ich würde ihn gerne hauen oder den, die oder wie auch immer, weil es eigentlich genau das nicht ist. Es ist eine Engine, um irgendwas zu amortisieren. Es könnte auch sein, dass es eben die Bind-Konfig oder sonst was ist, auf eine Maschine auszuräumen.

Aber ich kann genauso eben auch mit der gleichen Engine, mit der gleichen Sprache eine Maschine bei AWS provisionieren oder ein Port auf dem Switch hochnehmen oder da unten nehmen.

Ansible als solches bringt einen Haufen Module mit, die für viele, viele Sachen gut sind. Pakete installieren, Sachen konfigurieren, Nagios, Zabix, was auch immer. Aber natürlich nicht für alles.

Und damit eben jeder seinen eigenen Workflow abbilden kann, gibt es auch eine Schnittstelle, um eigene Module zu schreiben. Und das ist das, was wir im Endeffekt auch benutzen nachher und was ihr auch nachher sehen werdet. Und wie gesagt, Rest-APIs oder überhaupt APIs lassen sich mit Ansible sehr gut integrieren,

weil die Entwickler von Ansible halt gemerkt haben, es ist nicht alles nur ein Server, womit wir zu tun haben, sondern eine viel breitere Palette. Und wir müssten eben auch mit APIs und anderen Sachen sprechen.

Automatisieren ist ein gutes Stichpunkt. Warum eigentlich? Warum will ich das machen? Weil ich habe vorhin gesagt, ich bin faul. Ja, bin ich. Ich möchte Sachen nicht doppelt machen. Aber gleichzeitig möchte ich auch, dass jeder meiner Kollegen mit mir zusammenarbeiten kann, ohne dass ich den Kollegen irgendwie Prot-Zugriff auf meine Server geben kann oder will eigentlich.

Es gibt zum Beispiel ein Git, da sind Playbooks und irgendwie Variablen drin. Jeder kann einen Pull-Request erstellen und sagen, ne, keine Ahnung, wenn Server x deploit wird, bitte die Maschine nicht mit 2, sondern mit 4 GB RAM deployen.

Super valide, kann jeder machen, finde ich super. Gleichzeitig kann aber auch jeder hingehen und sagen, hey, du hast da jetzt, keine Ahnung, Tippfehler drin. In irgendeinem Pull-Request, also ich kann Pull-Review machen und den kann ich eben nicht, wenn ich in einer Oberfläche einfach Sachen anklicke und nicht automatisiert mache.

Ich kann aber auch, wenn ich festgestellt habe, ich habe Mist gebaut, und das tue ich oft, jeder eigentlich, ich kann ziemlich einfach einen Rollback machen. Sofern ich meine Information in einer strukturierten Art und Weise irgendwo niedergeschrieben habe,

kann ich auf die Version davor zurückspringen und diese Version wieder ausrollen. Und gleichzeitig kann ich diese Version auch 20 mal ausrollen auf 20 Umgebungen, die aber alle gleich aussehen sollen. Und natürlich, es ist meiner Meinung nach, I might be biased, wie es so schön heißt,

es ist lesbarer, irgendwie einen Jammel-Fall zu schreiben oder Tommel oder was auch immer für ein Format, anstatt Bash-Scripter und sonst was, auch wenn Bash im weitesten Sinne halt auch Automatisierung ist.

Das Warum wäre geklärt, nächste wichtige Frage wäre das Wie. Ich habe vorhin gesagt, Formen ist eigentlich eine Web-Überfläche. Grob gesagt ist es richtig, es ist eine Rails-App, sprich, ich könnte eigentlich hingehen

und irgendwelche Mausklicks da mit Selenium oder sowas automatisieren. Geht schon. Review von einem Selenium-Script, ja, viel Spaß. Von jemandem, der das selber wirklich mit der Maus in der Hand macht, Review nicht möglich. No way. Auch wenn ihr daneben sitzt, jemand wird daneben klicken und ihr werdet zu langsam sein.

Genauso ist auch das Zurückspringen zu der vorherigen Version eine Definition schwierig. Manche Web-Überflächen erlauben das, manche nicht. Nichtsdestotrotz wäre der Prozess hässlich. Und Reproducibility? Nee.

Ich kann fünf Browser-Fenster mit fünf Instanzen aufmachen und überall den gleichen Klick machen. Ich werde mich verklicken. Ich weiß nicht, wie es euch da geht, aber ich verklick mich dauernd. Ist halt so. Es ist natürlich so, Formen hat nicht nur eine GUI, wir sind alle Nerds, es gibt auch eine Shell.

Es gibt halt eine CLI, nennt sich Hammer, weil der Vorarbeiter hat natürlich einen Hammer in der Hand. Und naja, diese Shell oder dieses Shell-Tool kann ich automatisieren. Ich kann dann SRD, AWK drum herum jagen und ab dafür.

Ist eine Art Automatisierung, kann man schon so machen. Ihr seht mein Laptop nicht, da kann man so machen, ist aber ein Kackeaufkleber drauf. Weil ich finde es nachher nicht lesbar. Man kann es ein bisschen schöner machen, weil das CLI-Tool kann auch JSON und CSV ausgeben.

Dann kann man das ein bisschen mit JQ und JO bearbeiten. Aber nein, immer noch nicht. Ansible hat Command- und Shell-Module, nein. Falls irgendjemand mal probiert hat, da JSON rein und auch vor allem wieder rauszukriegen, kein Spaß.

Absolut kein Spaß. Deswegen, was nimmt man so als Programmierer? Als naheliegendste Nächste eine API. Eine API ist auch das Gleiche, was dieses Hammer-Tool vorher benutzt.

Also es ist eigentlich schon API-Client. Aber wenn ich eine API wieder um Shell rappe, ist es irgendwie doof. Deswegen, lasst uns doch mit der API direkt sprechen. Ich kann irgendwie meine Daten, die ja im Normalfall einen Zustand oder irgendwelche Informationen abbilden,

ich kann hier eine Datenstruktur buffen. Jaml, JSON, Tommel, you name it. Es gibt ganz viele davon. Es ist auch eigentlich egal, was für eine Datenstruktur ich nehme. Hauptsache, es ist strukturiert. Und ich kann mir irgendwie einen Client bauen, der mir aus den Daten, die ich verstehe, ein Format liefert,

was der Server nachher versteht. Server ist in diesem Fall mein Formel. Er hat eine stinknormale REST-API, die eben JSON kriegt und JSON zurückspuckt und zwischendurch mehr oder mal vielleicht 500 Maschinen deployed hat.

Dementsprechend, das ist da, wo ich ansetzen möchte. Und was ich auch ganz gerne benutzen möchte, weil es ist eben... Ich persönlich kann Jaml ganz gut lesen. Manchmal wird es hässlich, aber es ist schön, halbwegs. Und es erlaubt mir eben, meine Daten zu strukturieren.

Wir könnten einen API Client selber schreiben und ich werde ein paar Stellen sagen, was man jetzt nachher bei den Modulgeschreibsel sagen, wie man einen API Client schreiben könnte. Wir können aber auch einfach direkt Ansible benutzen, weil Ansible kann mit APIs umgehen.

Die Ansible Playbooks sind meiner Meinung nach relativ lesbar. Und ein bisschen HTTP und JSON rauspulvern dann eben an meine Formen. Kriegt das Ding schon hin. Es ist natürlich so, dass hier ist wie so oft so ein Werbetalk,

weil ich möchte euch zeigen, was ich gemacht habe. Aber es ist ja immer so, es gab da bestimmt schon mal was. Und zwar gibt es zwei Sachen, die funktionieren, aber die möchte ich nicht benutzen.

Nummer eins sind doch richtige Folie, Entschuldigung. Formen und Catello-Module. Es gibt zwei Module in Ansible Proper, also in Ansible Projekt Upstream, die dafür da sind eben mit Formen und Catello zu sprechen. Die gibt es dort seit der Version 2.3, also 2016 ungefähr.

Die sind aber in der aktuellsten Version 2.8 deprecated und werden in 2.12 entfernt. Unter anderem, weil ich das getan habe, was ich getan habe, also neue Module entwickelt. Die Module wurden von einem Kollegen von mir contributed, der auch nachher eben gesagt hat, das war eigentlich eine Scheißidee.

Da sind zwei Module, die aber als ein Modul alles können sollen. Das ist sehr schwierig zu dokumentieren, weil dann hat man irgendwie 20 Seiten Dokumentation für ein Modul, will keiner lesen. Aus dem Modulnamen ist nicht ersichtlich, was es macht,

außer dass es eben mit Catello oder Formen spricht. Und das Schlimmste ist, es benutzt eine Bibliothek, die für Red Hat Satellite geschrieben ist. Wer es nicht kennt, Red Hat Satellite ist ein Produkt auf Basis von Formen und Catello,

was aber dazu führt, dass die Bibliothek, die für Satellite geschrieben ist, die kann zwar mit einem Formen sprechen, wenn dann Catello mit dabei ist, aber sie kann auch nur in den Versionen sprechen, die in Satellite drin ist. Satellite ist ein Enterprise Produkt, es ist ein bisschen langsamer, was Releases angeht.

Aktuell ist zum Beispiel Formen bei 1.22 und 1.23 kommt in zwei Wochen raus. Das aktuelle Satellite Release ist aber noch bei 1.20. Dementsprechend hat man auf jeden Fall ein Gap an Features, die diese Bibliothek nicht abdeckt,

weil braucht sie nicht. Und wie gesagt, was ich viel schlimmer finde, ist, sie kann nicht mit Installationen, die kein Catello hat, arbeiten, überhaupt nicht. Und dementsprechend, die Module wurden Contributor, sie funktionieren für bestimmte Szenarien, aber sie werden bald entfernt, weil es eben was Besseres gibt.

Weil ich vorhin halt gesagt habe, die sind ein bisschen schwierig zu benutzen, hier mein Beispiel. Create Organization, einfach mal in Formen eine neue Organisation anlegen. Natürlich muss ich irgendwie einen Benutzernamen, Passwort und eine URL angeben,

weil sonst kann der Ding nicht mit der API sprechen. Dann muss ich aber relativ krude hingehen und sagen, ich möchte die Entity Organization anfassen. Entity ist der Begriff einfach einer Objektaart, sage ich jetzt mal, in Formen. Und dann übergebe ich denen halt eine Liste von Parametern.

Und durch diese Verschachtelung ist es echt, also es sieht jetzt bei Create Organization noch vergleichsweise okay aus. Hier sieht es nicht mehr ganz so okay aus, weil es sind auf einmal nicht ein Parameter, sondern fünf. Und wie die heißen und wo die herkommen,

dafür musste man eigentlich die API-Doku von Formen bzw. Catello lesen, um da sich vernünftig einen Reim drauf zu machen. Dementsprechend war das so ein bisschen dead-end und alle haben gemeinsam gesagt, nee, wir wollen das anders machen.

Gleichzeitig aber, oder sogar gar nicht gleichzeitig, sondern so ein bisschen vorher, gab es ein zweites Projekt und zwar Ansible Module Formen von Thomas Cran, ich glaube nicht anwesend gerade. Es ist ein Reporter, darauf geht es auch mit vielen einzelnen Modulen,

schon mal besser, für Formen. Das Ding ist gut gepflegt, wird auch bis heute weiterentwickelt, ist aber sehr Formen-spezifisch. Müsste also, wenn man wiederum mit irgendwelchen Formen, Plugins, sei es Openscape, sei es Ansible, sei es Catello arbeitet,

müsste man die Bibliothek, die das Ding unten drunter benutzt, relativ viel erweitern. Und naja, auch irgendwie Arbeit wollte ich jetzt auch nicht. Und es ist wiederum, es guckt oder es fragt,

das Formen nicht nach der API-Definition, die die laufende Instanz hat, sprich, es weiß nicht, welche Parameter der Server erwartet, was manchmal ein Problem sein könnte. Dementsprechend funktioniert, ist gepflegt,

da ich aber irgendwie bei Red Hat arbeite und mit Catello arbeiten soll, muss, will, war jetzt ein Set an Modulen ohne Catello-Support nichts für mich. Deswegen Werbeeinblendung, Formen, Ansible Modules. Das ist das, was ich euch heute gerne ans Herz legen möchte.

Es ist die, ja, im Endeffekt jetzt zweite, dritte Iteration von dem, wie wir uns vorstellen, mit Formen, mit Ansible ein Formen und ein Catello zu bedienen. Das Ganze gibt es jetzt 2017. Es ist daraus entstanden, dass wir gesagt haben,

die Module, die wir in Ansible haben, also Formen und Catello, das ist Mist, müssen wir mal aufsplitten, müssen wir mal aufräumen. Es ist Teil der offiziellen Formen-Organisation und nicht von Ansible, sondern wir sind Teil von Formen. Wir haben unsere Git-Repositories auf githubs.com,

wir haben unsere Dokumentation auf theformen.org, sprich voller Teil der Community und wir versuchen eben die Benutzung von Formen möglichst einfach, nicht vollständig einfach, so weit sind wir noch nicht, aber möglichst einfach zu gestalten. Wie gesagt, das Ganze ist entstanden durch Aufsplittung zuerst,

also haben die Formen und Catello-Module genommen, kopiert und gesagt haben, jetzt schneiden wir alles auseinander und es gibt ein Modul pro Entity, pro Endpunkt im Endeffekt in der API. Das war aber nicht so richtig genug, weil dann gab es immer noch keine Tests und auf einmal hat man aus einem Modul 20 gemacht

und oh, jetzt habe ich Code 20 mal rüberkopiert, geil. Also haben wir, nachdem wir die Module aufgesplittet haben, gesagt, jo, und jetzt ziehen wir nochmal so ein Abstraction-Layer da raus und erlauben dadurch, dass wir ja immer mit der gleichen oder mit der gleichartigen API sprechen

und immer nur anderen Input annehmen und anderen Output erwarten, verschieben wir mal das ganze generische Zeug irgendwie in so ein Framework und machen das Moduleschreiben dadurch viel einfacher.

Und was wir auch dazu gewonnen haben, sind viele Tests, weil wenn man Software schreibt und sie gegen Prot testet, funktioniert sie meistens, und wenn man morgen ein Komma ändert, funktioniert sie auf einmal nicht mehr. Ist doof, möchte man nicht, aber dafür hat man Tests.

Und ich muss mal kurz einen Schluck zu trinken nehmen, tut mir leid. Wie schon erwähnt, die Module sind erstmal aus dem entstanden, was wir schon hatten.

Was hatten wir? Wir hatten Module, die mit Nailgang gearbeitet haben, womit wir diese ganzen Probleme, die ich vorhin erwähnt habe, versionsspezifisch für Satellite, nicht für Catello, keine Funktionalität für Plugins, die nicht in Satellite drin sind,

weil warum sollte Red Hat Bibliothek-Support für Plugins haben, die Red Hat nicht schippt? Und eben dieses starre, ich brauche ein Catello, weil Catello ein paar API in Punkte umbiegt, Nailgang war es einfach irgendwie auf Dauer nicht.

Deswegen haben wir vor einiger Zeit, das war so Anfang 2019, gesagt, ja, müssen wir mal ändern, und wie ändern IT-Menschen, die machen selber was Neues, weil das, was schon gibt, ist ja irgendwie langweilig. Also haben wir eine Bibliothek in Python geschrieben, die das API-Doc,

welches Formen eh zur Verfügung stellt, liest und daraus API-Request-Manifect generieren kann. Das Ganze ist angelehnt an das Ruby-Bindings, die es dafür gibt, die es vorher schon gab,

weil eben Formen sind selber in Ruby geschrieben, und das Kommando-Zeilen-Tool hatte eben schon so ein Framework, um mit der API zu sprechen. Wer Swagger oder OpenAPI kennt, das ist so was Ähnliches, nur in etwas einfacher meiner Meinung nach.

Ist aber im Endeffekt egal, es gibt halt eine Definition, und an dieser Definition kann ich mich langhangeln. Und dann haben wir angefangen, wir haben gesagt, ja, wir haben jetzt eine Bibliothek, wir können damit arbeiten, jetzt müssen wir migrieren. Gott sei Dank hatten wir dieses Framework, was wir im Endeffekt wiederverwenden konnten,

wir konnten es recyceln, und wir mussten ja nur die Verbindung zur API neu aufbauen und die Suchmethoden neu machen und alles neu machen, aber es war trotzdem relativ, oder es ist relativ einfach, im Vergleich zu alles neu schreiben.

Und wir hatten Tests, wir konnten also sagen, es hat vorher so funktioniert, es funktioniert jetzt so. Ob es perfekt ist, bestimmt nicht, aber die vorherigen Test-Cases funktionieren jetzt immerhin. Ich sage, wir haben es noch nicht fertig gemacht, wir haben fast 50 Module aktuell,

knapp die Hälfte ist, glaube ich, migriert, nachher gibt es einen Link, falls jemand mitmachen möchte und zu viel Freizeit hat, gerne. Ansonsten muss ich dauernd Kollegen von einer Konkurrenzfirma, das klingt auch sehr geil,

aber in der Open Source-Wert ist es so, eigentlich ist man Konkurrent, aber man arbeitet zusammen an der gleichen Sache, ja, muss ich dir halt nerven, dass die das mal machen. Sehen wir mal ein Beispiel, folie hervor, wunderbar. Vorher hatten wir irgendwie eine Organisation erstellt, jetzt erstellen wir eine Domain,

also auch etwas sehr Einfaches, vom Konzept her in Formeln, natürlich wieder unten irgendwie Connection-Informationen. Da muss ich mal meine Ansible-Kollegen fragen, wie man das vielleicht irgendwie hübscher machen kann, um zu sagen, oder in einem Playbook sagen kann, hier, alles was Formen-Connections macht, bitte benutzt die gleichen Parameter, vielleicht gibt es da mal was.

Interessante Sachen sind aber wirklich die ersten beiden Zahlen, also ich sage, ich erstelle ein Domain namens Example Org und naja, gut, eine Description ist jetzt Example Domain, es ist vielleicht nicht so mehr deskriptiv als Example Org selber, aber es ist einfach.

Insbesondere sind das aber direkte Modulparameter, ich kann Ansible Doc auf das Modul drauf jagen, und es wird euch sagen, welche Parameter man mir geben muss. Dadurch, dass ich das Ganze auch gegen oder mit einer API-Spezifikation gegenstecken kann, wenn jemand irgendwie als Name da ein Integer angibt, kann mein Modul direkt sagen,

schon bevor der API-Request stattgefunden hat, Integer als Name, geh weg, gib mir den String bitte. So was Simples, hat vorher nicht funktioniert, jetzt gibt es hier mal ein bisschen kompliziertes Beispiel.

Ich merke gerade, vielleicht hätte ich nicht schwarzen Hintergrund nehmen sollen, aber ich hoffe, ihr könnt es trotzdem ein bisschen lesen. Das ist jetzt ein Catello-Modul, und zwar ist das Repository-Set, also wenn man eine Red Hat-Subscription hat und die in Catello reinlädt, kann man sagen, hier, Catello, synchronisieren wir bitte doch die folgenden Repositories direkt von Red Hat.

Das hier würde zum Beispiel Red Hat Enterprise Linux Server, also das Standard RHEL in der Version 7-Server, synchronisieren, oder enable, weil synchronisieren passiert nachher. Wie gesagt, vom Umfang der Daten, die ich eintippen muss, nicht zu wenig,

aber jetzt immerhin dokumentiert und validiert. Das Ganze hat uns mittlerweile ein ganzes 50 Sternchen auf GitHub gebracht, stand gestern Abend, ich habe heute nicht nachgeguckt,

aber ich sehe hier mindestens 20 Leute, die gleich auch bestimmt das schöne Sternchen klicken werden. Wir haben insgesamt 25 Contributors aktuell, und zwar, ich glaube, ich habe nicht sehr genau hingeguckt, zehn von Red Hat und sieben von Atex, die auch vorne einen Stand haben

und auch über Formen und Ocarino, also deren Enterprise-Produkt auf Basis von Formen erzählen. Und was ich sehr cool finde, ist, wir hatten in 2019, also in dem Jahr, was jetzt ein halbes Jahr alt ist, neun neue Contributors.

Ich behaupte zu mir selbst, um mein Ego irgendwie zu streicheln, dass es daran liegt, dass wir irgendwie in diesem Jahr so viel einfacher gemacht haben, Module zu schreiben und irgendwie zu contributen. Richtig beweisen kann ich es nicht, aber behaupten kann ich es ja, oder? Was ich aber wirklich zeigen kann, ist, dass wir irgendwie im Jahr 2018

ein ziemliches Contributorloch hatten. Und zwar haben wir 2017 angefangen mit vielen Kollegen von Atex und von Red Hat, gearbeitet, gearbeitet, gearbeitet, und dann kamen irgendwie keine neuen Leute mehr. Das passiert so, ich glaube so hier irgendwo auf dem Slide,

also es müsste 2018 Februar sein, wo der letzte Contributor aus diesem Balken im Endeffekt da war, und dann nichts. Das lag halt daran, dass wir ein Set an Modulen hatten, die funktioniert haben,

aber irgendwie wurde, also es wurde ein, bestimmte Workflows waren abgedeckt und danach kam irgendwie nichts Neues mehr, obwohl wir und auch Stand heute immer noch viele Workflows, die es in Formen gibt, nicht abbilden können,

weil wir noch kein Modul dafür haben. Das kann man ändern, das tut sich, also das ändert sich auch so langsam. Jetzt ab 2019, gefühlt ist cool. Wer übrigens mitgezählt hat, auf diesem Slide sind nur 23,

nicht 25 Contributors insgesamt, weil das Slide ist schon wieder ein Monat alt und ich wollte den Kollegen, der es für mich erstellt hat, nicht nerven wegen zwei Leuten irgendwie neue Slides zu machen. Den zweiten Graf der Greg, das ist übrigens der ehemalige Community Manager von Formen,

der jetzt mittlerweile bei Red Hat als Data Analyst für Open Source Communities arbeitet, gemacht hat, ist dieser. Und zwar wollte Greg mir damit zeigen, dass wir pro Monat vor und nach diesem Umbruch

von Anfang 2019, wo wir eben so ein Framework und diesen ganzen Umstrukturieren auf diese neue Bibliothek gemacht haben, auf einmal viel mehr Pull Requests auf GitHub hatten. Vor Februar, das ist da, wo wir eben das Framework eingebaut haben,

hatten wir 7,7 PRs im Schnitt im Monat und jetzt sind es 12,3. Ich finde, das ist ein Sprung. Man müsste dieses riesige Bubble da noch ein bisschen wegoptimieren. Das war nämlich die Zeit, wo wir das Framework reingebaut haben

und da musste halt viel Wachstum gefixt werden, ist halt so. Das ist Stand heute oder Stand vor einem Monat, weil, wie gesagt, Grafen sind ein bisschen älter. Ihr seid aber vielleicht hier, um zu wissen, was ist morgen, was ist in einem Monat,

was ist in einem Jahr. Ich hoffe, dass wir in einem Jahr viel weiter sind. Was ich aber sagen kann, dass in den nächsten Monaten wird es diese Module nicht nur als GitHub-Repository geben oder als Git-Repository, sondern eben auch als Ansible Collection auf galaxyansible.com.

Sprich, ihr könnt mit eurem Ansible Client einfach sagen, ich brauche die Formen-Module und er wird sie euch runterladen. Falls ihr irgendwie nicht direkt mit der Außenwelt sprechen könnt, weil super tolles secure Enterprise-Environment, dann gibt es auch klassische APMs.

Und wenn ich mich irgendwann mal dazu durchringe, wahrscheinlich auf Debian-Plakete, auf Formen.org und die könnt ihr dann eben wieder mit Catello synchronisieren und euren Clients zur Verfügung stellen. Das Ganze wird Ansible 2.8 benötigen, weil wir Ansible Collections dafür benutzen für die Distribution.

Die Module selber funktionieren oder wir bilden uns ein, dass wir keine Abhängigkeiten an Ansible selber haben, die nicht in Ansible 2.3 drin sind. Sprich, auch wenn ihr irgendwie ein etwas abgehangenes Environment habt und nicht auf 2.8 upgraden könnt,

auch wenn ihr solltet, bitte, da gibt es schon coole neue Sachen drin, es sollte mit 2.3 funktionieren. Bis hierhin Fragen. Nächste Abschnitt ist nämlich die Beispiele, die ich mitgebracht habe. Bitte schön.

Die Frage, wenn ich hier richtig, ah, da kommt ein Mikro,

aber ich kann die Frage einfach wiederholen, ob ich ein Problem sehe, dass Ansible Playbooks gegen ein normales Play in Formen laufen oder eben gegen ein Satellite, was anderes Formen als Unterbau hat und unterschiedlich wirkt dadurch. Stand heute ist es so, dass wenn du die alte, also die Nailgun-Bibliothek hast,

sie ist theoretisch nur gegen Satellite getestet. Funktioniert aber eigentlich in einem Formen-Setup, sofern es Catello hat, ohne Probleme. Durch die neue Bibliothek, die holt sich immer beim laufenden Server die API-Dokumentation.

Das ist ein riesiges JSON-File, wo alle API-Routen und alle Parameter drin stehen. Sprich, wenn ich mit einem Formen-Server spreche, wird er mir sagen, ja, Organisationserstellen machst du so und so. Wenn ich mit dem Satellite spreche, wird er mir sagen, ja, die Organisation musst du bei mir so und so machen.

Meine Bibliothek abstrahiert das weg. Das Modul sagt nur noch, erstellen wir eine Organisation. Sofern die API beschreibt, wie ich eine Organisation erstelle, kann ich das machen. Und dadurch, dass ich eben die Beschreibung, die API-Beschreibung immer von einem Live-Server bekomme,

stelle ich eigentlich oder versuche ich sicherzustellen, dass ich auch den Request korrekt generiere. Keine Garantien, wie immer, aber bis jetzt funktioniert das ziemlich gut. Genau, wenn es nicht funktioniert, ist es ein Bug. Entweder in der API-Dokument-Beschreibung, die existieren, oder eben in der Bibliothek, die der API passt.

Weitere Fragen? Nicht. Sehr gut. Dann habe ich euch vier Beispiele mitgebracht. Wie gesagt, durch meine Arbeit sind die etwas sehr cartello-lastig. Tut mir leid.

Nummer eins ist Cartello mit einem Repository im Content-View. Das ist eigentlich ein total super Standard-Beispiel. Und Gott sei Dank kann man das mit den Modulen abdecken. Schritt eins ist ein Cartello-Repository-Set.

Das ist eben das Modul, wie ich es vorhin schon erwähnt habe, das ein Repository-Set von Red Hat nimmt und es in eurem Cartello aktiviert. Dann gibt es eben das Produkt und das Repository. In diesem Fall RHEL7. Existiert es dann im Cartello oder im Satellite. Und als nächsten Schritt kann ich sagen, jo, ich mache jetzt einen Content-View.

Also ich nehme ein Repository und packe daraus etwas, was ich einem Client zur Verfügung stellen kann. Hier vergleichsweise langweilig. Ich nehme mein Content-View einfach RHEL und packe da mein Enterprise Linux 7 rein. Und das Ding ist fertig. Ich könnte das publishen und an meine Clients weiterreichen.

Ich könnte aber auch genauso hier mehrere Repositories aufzählen und sagen, ich habe hier einen RHEL mit, keine Ahnung, mit einem Nagios, damit es richtig schön alt ist. Content-View erstellt erst einmal nur ein Objekt in der Datenbank. Davon sehen die Clients noch nichts.

Deswegen muss ich auch noch Repository synchronisieren und publizieren bei Cartello. Nächstes Beispiel. Vorhin haben wir ein Repository enabled. Dann führen wir in Cartello Sync aus. Ich habe mir übrigens auf diesen ganzen Slides irgendwie immer die Connection-Informationen gespart,

weil ansonsten habt ihr alles doppelt und dreifach und keinen Mehrwert. Ich habe hier so ein dreischrittiges Workflow. Ich synchronisiere alles, was ich von Red Hat an den Linux-Server bekomme. Dann mache ich ein Publish von meinem Content-View. Den Content-View habe ich auf der Slide vorher erstellt.

Der nennt sich RHEL. Dann mache ich ein Publish davon. Jetzt fehlt hier eigentlich ein Schritt. Jetzt könnte ich hingehen und sagen, du Ansible, sprich doch mal mit dem OpenStack da hinten. Fahr mir mal eine VM hoch und teste mal das neuere RHEL, was ich jetzt gerade frisch synchronisiert habe mit meiner tollen Applikation.

Und erst wenn diese ganzen Tests, die irgendwo durchgelaufen sind, würde ich dann zum Schritt 3 gehen und sagen, grundsätzlich nenne ich das jetzt mal ein bisschen getestet und promote das in Lifecycle-Environment, also in den nächsten Schritt bei Cartello,

wo dann mehr Clients das Ganze sehen können. Das ist ein mehr oder weniger Live-Beispiel. So wird nämlich Red Hat Satellite bei uns entwickelt oder getestet. Wir haben natürlich ein riesiges QA-Team, was irgendwie auch eine riesige Testsuite hat.

Aber bevor die Testsuite und Menschen tatsächlich mit der Software arbeiten und verifizieren wollen, will man so ein bisschen sicherstellen, dass eine neue Version nicht Dead on Arrival ist. Und so machen wir das intern. Wir synchronisieren RHEL und eben auch Satellite-Binaries, die wir gebaut haben,

publizieren sie in einem kleinen Content-View, wo nur eine einzelne FAM-Embendigung drin hängt. Sie testet, das Ding ist installierbar und wenn wir das Ding starten, kommt eine Web-Oberfläche vor hoch. Das ist so minimal, aber dadurch können wir sicherstellen,

dass zumindest das Ganze installierbar ist. Und ich habe jetzt nicht irgendwie Kollegen gesagt, hier, da ist der neueste heiße Scheiß und sie sagen, nee, kann ich nicht installieren. So könnte man es zum Beispiel abbilden. Man kann das Ganze auch leicht schneller machen und sagt,

Publish und Promote mache ich im gleichen Schritt. Ist manchmal praktisch, wie gesagt. Dadurch kann man aber hier jetzt natürlich keinen Zwischenschritt mehr einbauen und sagen, ja, ich möchte aber, bevor ich etwas an Systeme weitergebe,

möchte ich das vielleicht auch mal testen. Nächstes Beispiel ist auch, etwas, das wir tatsächlich genau so machen, ist, wenn wir einen Snapshot releasen, also wir releasen jeden Freitag einen Snapshot,

wo wir sagen, hier, das sind die Änderungen, die letzte Woche passiert sind, die könnte man jetzt irgendwie theoretisch auch public irgendwie machen. Wir wollen aber von jedem Snapshot eine Archivkopie haben. Sprich, bei jedem Snapshot gehen wir her und sagen, wir stellen neues Lifecycle-Environment in Catello.

Schritt 1, Lifecycle-Environment. Und dann machen wir einen kleinen Trick. Wir wollen nämlich, dass diesen Snapshot automatisch installierbar machen. Dafür nehmen wir einen Activation Key in Catello, was im Endeffekt ein Pointer ist auf eine Liste von Subskriptionen und Content Views,

oder einen Content View. Und wenn ein Client mit diesem Activation Key zum Catello kommt, kriegt er auf jeden Fall die gleichen Subscriptions und er kriegt auf jeden Fall den Content aus diesem bestimmten Content View. Und wir gehen dann halt her und sagen,

wir nehmen einen existierenden Activation Key, wir kopieren den, weil er ist schon vorbereitet, er hat die richtigen Subscriptions und fast alles korrekt. Und dann verschieben wir das Ganze in Lifecycle-Environment, was wir vorher erstellt haben, wo wir dann unsere Archivkopie hinterlegen. Nächstes Beispiel, Formen Cleanup, das ist von den Kollegen aus München.

Sie benutzen die Module nämlich, um ihre Formen zu testen. Es werden viele, viele Sachen auf den Formen geändert und irgendwann muss man halt aufräumen. Also geht man hin und sagt, man löscht doch bitte mal alle Installation Mediums.

Viele der Module unterstützen so ein Name-Sternchen, was dazu führt, dass eben nicht ein bestimmtes Installation Medium angesprochen wird, sondern alle und wir können damit einfach alle löschen. Genauso können wir alle Provision-Templates und Partitioning-Templates entfernen.

Damit ist so ein Formen zwar nicht komplett leer, also nicht ganz virgin, wie er installiert worden ist, aber zumindest ein bisschen gereinigt und könnte wieder mit frischen Informationen getankt werden. Jetzt habe ich ungefähr 45 Minuten gequatscht. Ich wollte weniger, weil jetzt kommt eigentlich das Interessanteste.

Jetzt kommt Module schreiben. Das, weswegen ihr alle hier seid, weil ich brauche eure Contributions. Die meisten Module, die wir so irgendwie zumindest im Formenumfeld haben, sind alle gleich aufgebaut oder sehr ähnlich.

Meistens geht es darum, ein Objekt, was in Formen existieren soll, zu beschreiben. Und dann geht dieses Modul hin. Entweder es findet dieses Objekt und es gleich die Information, die der User eingegeben hat, mit den Informationen, die in Formen sind. Wenn die gleich sind, dann ist geil, kann man weitermachen.

Wenn die nicht gleich sind, muss eben das Objekt in Formen abgedatet werden, weil der User hat immer recht, hoffentlich. Oder wenn es eben gar nicht gefunden worden ist, muss eben das Objekt angelegt werden. In jedem Fall, sowohl beim Anlegen als auch beim Updaten, einmal speichern, fertig.

Das ist so das relativ gängige, was die meisten Module bei uns machen. Deswegen haben wir ein Framework geschrieben oder eben Abtraktionsebenen. Wer schon mal ein Ansible-Modul selber geschrieben hat, hat auf jeden Fall mal irgendwie aus Ansible-Module-Utils mal Ansible-Module importiert,

weil das ist so das Basic, was irgendwie das Argumente annehmen vom Ansible-Commandline oder auch von Ansible Playbook sicherstellt und irgendwie auch ein paar Helferlines bietet, um User-Feedback zu geben, um Fehler zu reporten und so weiter. Da alle unsere Module irgendwie erstmal ein Grundsatz oder ein Grundset an Argumenten annehmen,

also Server-Name, User-Name, Passwort, ob man SSL-Zertifikate verifizieren möchte oder nicht. Es gibt Leute, die tun das nicht. Haben wir eben einen Rapper um das ganze Ansible-Modul geschrieben,

um diese immer wiederkehrenden Sachen gar nicht mehr angeben zu müssen. Weil spart fünf Zeilen Code, also damit auch fünf Zeilen, in denen ich irgendwie Fehler machen kann. Und naja, weniger Platz für Fehler ist eigentlich immer gut.

Und dann insanziere ich halt eben mein Formel-Entity Blablabla-Modul. Tut mir leid für den langen Namen. Das liegt daran, dass wir eben aktuell noch zwei Backend-Bibliotheken unterstützen und Unterschied zwischen Formel- und Catello-Entities machen, weil sie unterschiedliche Argumente annehmen.

Deswegen langer Klassenname, auch wenn wir nicht bei Java sind. Ok, Java-Bashing für heute erledigt. Und wer schon mal ein Ansible-Modul geschrieben hat, wird irgendwie sagen, hä, warum hast du denn da Entity-Spec stehen, das heißt doch Argument-Spec. Ja, richtig. Bei Ansible heißt es Argument-Spec.

Und es sieht auch wie ein Argument-Spec aus hier. Wir benutzen es aber ein bisschen erweitert. Deswegen haben wir gesagt, wir möchten Entity-Spec haben, weil wir dadurch auch einige Differenzen zwischen Ansible und Formen damit einfacher ausmerzen können.

Dazu gleich noch ein genaueres Beispiel. Hier ist es erstmal nur ein Ist-Modul, es akzeptiert irgendwie Namen. Und wenn wir irgendwie Argumente vom User angenommen haben,

was macht man als nächstes? Muss sie vielleicht ein bisschen aufräumen, ein bisschen schauen, dass sie valide sind und natürlich Verbindungs-AP herstellen. Wiederum triviale Funktionalität, für die wir irgendwie eine Vereinfachung haben.

Wir haben eine Funktion, die heißt CleanParams. Das schmeißt zum Beispiel alle Parameter, die mit der Verbindung zu tun haben, weg. Beziehungsweise speichert sie an eine andere Stelle, weil in dem Modul, also in dem Entity, also in dem Objekt, was ich eigentlich bearbeiten möchte, interessiert mich das Passwort von dem Benutzer nicht mehr.

Und dann ruft man Modul-Connect auf, was die API-Verbindung aufbaut. Das API-Doc pullt, wenn es noch nicht da ist auf der Platte im Cache. Und damit auch automatisch sicherstellt, dass irgendwie Benutzernahmen, Passworte und URL überhaupt stimmen.

Und wenn nicht, gibt es halt einen Fehler. Ihr werdet feststellen, es gibt irgendwie kein Try-Except auf den ganzen Folien, weil die meiste Fehlerbehandlung ist in den Formen Ansible-Module als Abstraktion schon drin. Da müsste man sich nicht darum kümmern.

Wieder drei Zeilen gespart. Das Modul, was ich mit euch hier irgendwie kurz durchdiskutieren möchte, ist Architecture. Das ist ein relativ einfaches Entity in Formen. Im Endeffekt ist es nur irgendwie x86 und PowerPC 64, was auch immer.

Und ist nur zum Klassifizieren von Betriebssystemen da. Ich gehe also hin und habe vorhin ja meinen Namen irgendwie schon mal bekommen vom User. Also kann ich zur API hingehen und sagen, hier, finden wir doch die Ressource vom Typ Architecture,

die den Namen, das was auch jemand der User eingegeben hat, hat. Nachdem das aufgerufen worden ist, ist Entity entweder none, weil wurde nicht gefunden. Oder es beinhaltet die Information, die Formen über diese Architecture kennt.

Nächster Schritt. Ich habe nach dem Namen gesucht, mal gucken, was die anderen Parameter sind, die Formen über dieses Ding kennt. Und ich möchte wissen, ob es geändert hat oder nicht. Es gibt wieder eine Funktion dafür, EnsureEntity. Ich möchte hingehen und sagen, hier, Architecture ist das, worum es mir geht.

Ich habe EntityDict, das ist das, was der User eingegeben hat. Ich habe Entity auf der anderen Seite, das ist das, was Formen kennt. Bitte verschmelz das doch Ganze. EnsureEntity wird im Hintergrund hingehen und sagen, jo.

State war absent oder state war present bei dem Modulaufruf. Also mache ich das entsprechend. Wenn die Entities gleich sind, wird nicht, also change wird als false zurückgegeben. Und wenn Änderungen vorhanden waren, wird true zurückgegeben.

Und ich kann das wieder mit dem normalen exe.json, was eben das Ansible eigene Funktionalität ist, um an den User zu reporten, jo, es gab eine Änderung. Ihr werdet meckern, es wird nur das change zurückgegeben, es wird kein div zurückgegeben. Ja, weiß ich, wissen wir, ist irgendwo auf der To-do-Liste.

Div-Support müsste relativ einfach einzubauen sein, aber hat noch keiner gemacht. Ja, und eigentlich war es das alles schon.

13, 14 Zeilen Text, Code, und ich kann eine Architecture in Formen erstellen. Es, werdet ihr sagen, eine Architecture hat aber doch bestimmt mehr als nur den Namen. Ja, hat sie, sie hat genau ein weiteres Feld, das ist irgendwie der Verweis auf ein Operating System. Oder auf eine Liste von Operating Systems.

Weil Architecture ohne System ist irgendwie langweilig. Und das ist das, was Formen abbildet. Ich müsste also vorher irgendwelche Operating Systems erstellt haben und erweitere mein Modul jetzt um eine Zeile in einem EntitySpec.

Und hier sieht man dann auch, warum wir nicht das Ding von Ansible direkt benutzen können, ist, wir möchten vom User eine Liste annehmen, das kann Ansible. Wir möchten Operating Systems nennen, weil, naja, das ist irgendwie für den User logisch zu sagen, hier Operating Systems sind Debian und Ubuntu.

Oder Red Hat und CentOS, was auch immer. Die API von Formen möchte aber eigentlich ein Array aus IDs haben. Deswegen gehen wir hin und sagen, Jo, UserInput ist Operating Systems, aber der Flatname, den wir nachher in die API zurückgeben, ist OperatingSystem-IDs.

Das ist etwas, was das Ansible ArgumentSpec nicht beherrscht, weil es weiß auch nicht, was Formen-IPA ist, deswegen haben wir das hier erweitert. Wir haben jetzt also ein Modul, was zwei UserInputs bekommt,

aber auf der Folie vorhin haben wir mit dem zweiten noch nichts gemacht, weil kannten wir noch nicht. Also müssen wir ja ein paar mehr Zeilen schreiben. Ihr könnt auch noch die letzten fünf Minuten zuhören, das ist bestimmt spannend. Ja, fünf mehr Zeilen, oder fünf Zeilen mehr.

Und zwar gehen wir hin und sagen, wenn nicht absent oder desired absent, weil wenn wir etwas löschen, müssen wir nicht mehr gucken, für welche Operating Systems die Architektur gehört. Wir wollen die nur weghaben. Wenn wir die aber nicht weghaben wollen und der User Operating Systems angegeben hat, was optional ist,

gehen wir hin und sagen, jo, finden wir mal zu den Namen, die der Benutzer angegeben hat, die richtigen IDs, und packen das in eine Liste. Das ist alles, was wir als Entwickler machen müssen.

Den Rest, also das Updaten, übernimmt wiederum die Abtraktionsschicht darunter. Ihr seht hier, es gibt für Operating Systems gibt es einen Helfer, also eine eigene Funktion. Für die meisten andere Entities gibt es das nicht. Einfach, was im Grunde das Operating Systems ein bisschen wirr sind in Formen.

Und wir deswegen eine etwas kompliziertere Suche machen. Für normale oder mehr übliche Suchanfragen könnten wir auch hingehen und sagen, ja, wir generieren einfach eine Liste von Suchbegriffen oder Suchanfragen.

Hier habe ich jetzt irgendwie Title tilde irgendwas gemacht. Ich könnte auch Title gleich etwas machen. Und übergeben das eine eine generische Find Resources Funktion. Das ist nicht der gleiche Gut wie vorhin. Also das Ergebnis hier wäre ein anderes.

Aber auch hier, wir bieten eine Abtraktion an, aber ihr könnt auch irgendwie eine Schicht darunter gehen und selber Suchanfragen stellen, falls ihr mit einem Objekt arbeitet, was komplizierter ist. Ich werde hinten darauf hingewiesen, dass ich noch fünf Minuten habe. Das ist super, denn letzte Folie, links draufklicken.

Und zwar am besten auf den letzten. Das ist nämlich die Issue 274. Das ist unsere Migrationsliste für eben um Module von der alten Bibliothek auf die neue. Du musst kein Foto machen.

In dem Foliensatz, was gerade auf frostcon.de drauf ist, ist diese Folie noch nicht drin. Ich werde es gleich hochladen. Es funktioniert ja, Gott sei Dank. Ja, wie gesagt, Docs sind auf der Forman-Org, GitHub ist GitHub, kennt man ja. Und damit vielen Dank fürs Zuhören und habt ihr Fragen.

Ja, da hinten, ich weiß nicht, wie viel zu laufen.

Nochmal bitte, ich habe es akustisch nicht gut. Auf Tools ist ja oft das Problem, die Bugging-Unterstützung. Was habt ihr da an Sachen vorhanden bzw. geplant?

Was genau möchtest du debuggen? Also das Problem, wenn ich eine Anfrage, eine API-Anfrage stelle und die Gegenseite kann diese Anfrage nicht beantworten? Oder nicht verarbeitet meinst du z.B. sowas? Also erst mal, ich kenne das z.B. von Make, dass man sagen kann, dry run.

Sag doch mal, was du machen würdest, wenn ich dir die Parameter gebe und ich das ihnen übersichtlich oder einfach meinen Simple dargestellt kriege. Alle Module unterstützen dry run oder Check-Mode, wie es bei Ansible heißt. Nicht alle unsere Module, Jan Piet.

Die können das, wir sind cool. Da aber, wie vorhin gesagt, wir aktuell keine DIV-Unterstützung haben, hast du zwar den Output, es hätte sich was geändert, du siehst aber noch nicht was. Absolut valide, ist auf der To-do, muss gemacht werden, damit es richtig cool ist.

Aber zumindest würdest du sehen, dass sich was geändert hat. Du kannst auch den API-Request dir ausdampen lassen mit Verbose, um den sie selber anzuschauen. Ob du das möchtest, ist eine andere Frage.

Ein Minimum, drei, zwei, eins, verkauft. Vielen Dank.