Es scheint einfacher zu werden. Heute haben wir einen kleinen Spaziergang unternommen und sind an einer Schule mit dekorierten Fenstern vorbei gekommen.

<div style="clear: both" />

Der kleine Weihnachtswichtel hatte Spaß beim einpacken von Geschenken. Zwar war es noch ein Geburtstagsgeschenkt, aber wollen wir mal nicht so streng sein.

<div style="clear: both" />

Noch ist es gar nicht so einfach etwas weihnachtliches draußen zu finden. Daher heute nur eine Licherkette in einer schäbbigen Ecke.

<div style="clear: both" />

Dieses Jahr war fotografisch gesehen eher ein schlechtes. Die meisten der Fotos aus 2015 zeigen wohl das Baby. Zumindest bekomme ich beim überfliegen der Bilder in Darktable diesen Eindruck.

Um dieses Jahr doch noch mit ein paar anderen Fotos zu Ende zu bringen, möchte ich jeden Tag ein Foto-Türchen öffnen. Dafür gehe ich jeden Tag raus und versuche etwas weihnachtliches vor die Linse zu bekommen. Gleich am ersten Tag hat dies nicht so gut funktioniert. Zwar habe ich etwas gefunden, doch das Baby wollte lieber nach Hause und hat mir keine Ruhe gelassen. Daher gibt es heute "nur" unseren Weihnachtsstern.

<div style="clear: both" />

Dieses Jahr war ich außergewöhnlich selten in Hamburg. Letztes Wochenende war tatsächlich das erste, dafür aber nicht das letzte Mal. Über Weihnachten und zum Congress werde ich auch dort sein.

Da eigentlich sogar relativ viel Zeit war, wir waren von Donnerstag bis Sonntag dort, habe ich meine Laufsachen mitgenommen und mich schon auf meine traditionelle Alsterrunde gefreut. Zum einen ist die Runde wirklich schön. Ohne Verkehr und die ganze Zeit am Wasser entlang, mal abgesehen von dem je 2km langen Hin- und Rückweg. Außerdem freue ich mich über jeden Kilometer, den ich nicht auf meinen gewohnten und mittlerweile ziemlich langweiligen, Strecken zurücklegen muss.

Hoffen auf die letzte Chance des Jahres über Weihnachten.

Wie in jedem Jahr habe ich auch Anfang dieses Jahres wieder das Ziel 1000-Laufkilometer-Plus ausgerufen. Das Klingt erst einmal nach gar nicht so besonders viel. Doch im vergangenen Jahr habe ich diese wirklich erst auf den letzten Drücker, nämlich am 30.12.2014 geschafft.

Für gewöhnlich laufe ich ca. 10km Runden. D.h. also 100 mal laufen, verteilt auf 52 Wochen. Zweimal pro Woche klingt erst einmal auch nicht so viel. Es kommen aber immer noch Urlaube und Krankheiten hinzu, und ganz schnell wird es knapp.

Dieses Jahr hat wirklich schleppend angefangen. Ich bin einfach nach der Arbeit nicht mehr so gut los gekommen. Winter und Dunkelheit haben ihr übriges getan. Dennoch habe ich bis Ende Juni ganz knapp über 500km geschafft. Der Juni stand ganz im Zeichen unserer 4 wöchigen Radtour in Südschweden. Also kein einziger Laufkilometer. In den August bin ich wegen einer Hochzeit und zurück-sei Besuchen auch erst am 13. gestartet.

Da meine Alleine-Elternzeit angefangen hat, hatte ich völlig berechtigte Hoffnung die 1000km auch in diesem Jahr wieder zu knacken. Und tatsächlich. Das Laufen mit dem Kleinen klappt wirklich hervorragend. Wir sind mit einem alten Chariot Cougar I unterwegs und für den Kleinen scheinen die 1 bis 1 1/2 Stunden sehr ertäglich zu sein. Die meiste Zeit schläft er. Doch selbst wenn er aufwacht, hat er Spaß. So ausgestattet sind wir 3 bis 4 mal die Woche unterwegs und schrubben Kilometer. Das schönste daran. Wir können raus wann immer wir wollen. Trotz kurzer Tage heißt das: Immer im hellen laufen!

Lange Rede kurzer Sinn. Bereits Mitte November habe ich die 1000km erreicht. Alles was jetzt kommt ist Zugabe :-)

Am vergangenen verlängerten Wochenende haben wir uns eine kleine Ferienwohnung in Kaltenhof auf der Ostseeinsel Poel gemietet. Gefühlt besteht ganz Kaltenhof nur aus Ferienwohnungen.

Gestartet sind wir am Gesundbrunnen. Von dort aus die ODEG nach Wismar genommen. In Wismar angekommen, haben wir uns mit den Rädern direkt in Richtung Poel gemacht, um noch im hellen dort anzukommen.

Auf der Fahrt zwischen Wismar und Poel war noch hervorragendes Wetter. Nicht zu kalt, nicht zu warm, und da wir relativ spät unterwegs waren, mit herrlichem Licht.

In Kaltenhof angekommen, haben wir nur noch die Wohnung bezogen und selbst gepflückte Äpfel aus dem Garten geschenkt bekommen. Freitag war es noch schön und wir haben in zwei längeren Spaziergängen den nördlichen Teil der Insel erkundet.

Unser erster Weg hat uns natürlich ans Meer gezogen.

Unsere Runde ging von Kaltenhof über Am Schwarzen Busch und Kirchdorf wieder zurück. Von der Ostsee weg ging es durch Felder und kleine Häuserssammlungen.

Vorbei an einer kleinen Fahrradwerkstatt.

Gegen Nachmittag sind wir nach Gollwitz und von dort entlang der Küste wieder zurück.

Entlang am Leuchtturm Gollwitz …

… durch einen kleinen Waldstreifen direkt an der Küste. Da keine Blätter mehr an den Bäumen hingen konnten wir die ganze Zeit über das Wasser sehen.

Entlang der Küste gibt es immer wieder Lichtungen mit einer Trimm dich Station. An jeder Lichtung ein anderes Gerät. Dazu die Beschreibung was man überhaupt tun soll und wie das Gerät gedacht ist. Bei dem Ausblick macht das vielleicht sogar Spaß?

Für den Samstag war das Wetter nur solala gemeldet. Eigentlich für den ganzen Tag Schauer und heftiger Wind… immerhin mit 3 Sonnenstunden. Mit den ersten blauen Löchern im Himmel haben wir uns auf die Fahrräder geschwungen und sind, gegen ordentlichen Wind an, nach Timmendorf gefahren. Dafür sind wir am Strand durch Kit-Surfer entschädigt worden.

In Timmendorf haben wir die erste und einzige offene Lokalität des Wochenendes gefunden. In einem einsamen Cafe gab es mittelmäßigen Kaffee und Kuchen, wenigstens zu günstigen Preisen.

Der erste Teil des Rückweges ging entlang der Steilküste. Zuerst direkt, dann mussten wir mit den Rädern hinter ein Waldstück. Es wurde einfach zu gefährlich mit Hänger.

Uns hat ein orderntlicher Regen erwischt, der nicht mehr aufhören wollte. Gut, dass wir vernünftige Regenklamotten haben.

Ein schöner Tag, für einige von uns sehr anstrengend ;)

Der Sonntag bestand nur aus der Fahrt durch den Regen zurück nach Wismar und der Zugfahrt zurück.

Ein wirklich schönes Wochenende. Poel ist auf jeden Fall eine Empfehlung. Vielleicht nicht unbedingt im Sommer, im Frühling und Herbst ist es dort schön ruhig. Eigentlich sollte man viel häufiger solche kleinen Trips unternehmen.

… Alle Fotos

<div style="clear: both" />

Diese Nachricht erreichte mich zumindest gerade via besagtem Protokoll, zusammen mit dem Hinweis auf den Artikel auf Heise FastMail: Google und Facebook graben XMPP das Wasser ab.

Doch was ist eigentlich passiert? Eigentlich nichts weiter. XMPP ist einfach nur wieder in der Nische, in der es auch vor Talk und Facebook Chat war.

XMPP hat einfach nur den Weg in die breite Masse nicht gefunden. Dies wird zum einen technische Gründe haben, als auch auf den Plattformgedanken der großen Player zurück zu führen sein. Facebook und Google haben kein Interesse an einem dezentralen Chat-Netzwerk.

Dazu sehe ich keine XMPP-Killer-App. Usability ist mitunter eine Katastrophe. Es ist nach wie vor schwierig Dateien untereinander auszutauschen! Ganz zu schweigen vom Einrichten neuer Accounts oder Video-Chats. Ja. Die Leute wollen Video-Chats. Und ja, es ist technisch auch mit XMPP Jingle möglich. Doch erklär das mal jemand der eigenen Mutter, wenn Video-Chat nicht funktioniert, weil man lieber Client-XY benutzt, und sie nur ihren Enkel sehen möchte.

Wenn XMPP die beste Erfindung seit geschnitten Brot wäre, würde es wohl kaum so viele Chat-Systeme geben, für die sich ein eigenes Protokoll ausgedacht wurde. Und das nicht nur bei den beiden "Großen". Siehe Telegram, matrix.org, Slack, you name it.

Man mag das alles ganz schlimm finden. Auch dass man gefühlt für jeden Menschen mit dem man kommuniziert eine andere App auf dem Smartphone installiert hat. Doch sterben wird XMPP meiner Ansicht nach nicht. Mir ist es völlig unklar wie viele und welche Chat-Systeme unter der Haube auf XMPP setzen. Es sind sicherlich noch einige. Außerdem steht es jedem frei einen XMPP-Server zu betreiben und somit das dezentrale Netzwerk zu stärken.

Ich persönlich bin weit davon entfernt an etwas festzuhalten nur weil es schon immer da war. Vielleicht funktioniert es eben doch nicht so gut wie viele Messanger es benötigen. Wenn XMPP wirklich zu Grunde geht, dann soll es wohl so sein. Es wurde IMHO versäumt, das Umfeld zu entwickeln, das die Leute brauchen.

Today I discovered this in salt.

Someone tries to test the function iptables.get_saved_rules in salt/tests/unit/modules/iptables_test.py#L149

@patch('salt.modules.iptables._parse_conf', MagicMock(return_value=False))
def test_get_saved_rules(self):
    '''
    Test if it return a data structure of the rules in the conf file
    '''
    self.assertFalse(iptables.get_saved_rules())

But in fact acutally nothing is tested at all. Literally nothing.

So lets have a look at the corresponding code. salt/salt/modules/iptables.py#L471

def get_saved_rules(conf_file=None, family='ipv4'):
    '''
    Return a data structure of the rules in the conf file
    CLI Example:
    .. code-block:: bash
        salt '*' iptables.get_saved_rules
        IPv6:
        salt '*' iptables.get_saved_rules family=ipv6
    '''
    return _parse_conf(conf_file, family)

This function just forwards some parameters to another function _parse_conf. The above test mocks out exactly this call, but does not check anything about the mock. This test does not even cover deleting the only statment in this function! This is caused to self.assertFalse, which is not very strict and accepts None as False.

However, I discovered this code, since ipv6 is not working correctly, due to wrong parameter passing to _parse_conf. Having a look there, shows us the use of keywords-only.

def _parse_conf(conf_file=None, in_mem=False, family='ipv4'):
    '''
    If a file is not passed in, and the correct one for this OS is not
    detected, return False
    '''
    ...

So in case of get_saved_rules, ipv4 is passed as parameter in_mem instead of family. So the code always runs the ipv4-path.

Long story short. If you are mocking. Check if your expected call really happened. This code really tests the call for _parse_conf, with expected parameters:

def test_get_saved_rules(self):
    '''
    Test if it return a data structure of the rules in the conf file
    '''
    mock = MagicMock(return_value=False)
    with patch.object(iptables, '_parse_conf', mock):
        self.assertFalse(iptables.get_saved_rules())
        mock.assert_called_with(conf_file=None, family='ipv4')

Even this is not best practice, since calling stuff on mock objects, also silently irgnores errors. e.g. mock.fajdslksahgalds() would work totally fine, without any info. Most important in such cases. Write your test before the code, so you see the test failing once.

… Yes. I opened pull requests for both issues.

TL;DR: Vollautomatisierung hilft die Migration immer wieder zu testen

In der letzten Zeit habe ich diverse Workshops zum Thema Orchestration gegeben. Zusammen mit meinem geschätzten Kollegn Jan haben wir Gruppen von 3 bis max. 10 Leuten den umgang mit OpenStack Orchestration (Heat) nahe gebracht. Dabei haben wir uns ausschließlich auf Heat Orchestration Templates (HOT) konzentriert. Unsere Teilnehmer waren in einigen Fällen Admins oder DevOps (sie wurden als solche vorgestellt) und weitaus häufiger Software Engineers/Architects.

So viel erst einmal zur Situation. Heat verwende ich hier nur als Synonym für jedes x-beliebige Tool, mit dem eine verteilte Anwendung aufgesetzt werden kann. Ein weiteres Beispiel, dieses mal für Container, wäre Googles Kubernetes.

Was haben wir den Teilnehmern beigebracht? #

Nachdem wir die einzelnen OpenStack-Komponenten gezeigt haben, die sich mittels Heat steuern lassen, sind wir direkt zu Heat selber und HOT gegangen. Als einfaches Szenario hat immer eine Applikation mit mehreren Application-Servern, einem davor sitzenden Loadbalancer und einem Datenbank-Server gedient. Auf primitivste Weise haben wir ein Service-Discovery gebaut, so dass neue Application-Server ins LoadBalancing aufgenommen werden. Das zuletzt verwendete Beispiel findet sich im Github Repo example-projects.

Wir haben gezeigt wie mittels HOT eine Infrastruktur inklusive Netzwerk und Firewall ausgerollt werden kann. Innerhalb der VMs wird (wie auch bei AWS) cloud-init angestoßen. Mittels diesem werden die nötigen Anwendungen installiert, konfiguriert und gestartet. Mit diesen kleinen Automatisierungen ist es auch möglich beliebig viele Application-Server nachträglich einzuzufügen. Natürlich gehört in der Realität etwas mehr dazu VMs komplett zu provisionieren und eine Applikation zu deployen. Aber als Proof-of-Concept ist das immer ganz gut angekommen.

Wir wollen den Teilnehmern mehr mitgeben #

Zum einen zeigen wir, wie einfach es sein kann, eine komplett neue Infrastruktur mit allen Komponenten hoch zu ziehen. Viel wichtiger aber ist die sensibilisierung auf Cloud-Best-Practices. Siehe dazu The twelve-factor app, oder mein persönliches Fazit zu docker.

Für ein Projekt ergeben sich durch die vollständige Automatisierung gleich mehrere Vorteile. So können Entwickler und QA die Applikation quasi im Production-Environment testen. Dadurch wird die Automatisierung auch immer und immer wieder getestet. Man hat also immer Übung für den Ernstfall: Alles muss von Grund auf neu aufgebaut werden.

Das starten und provisionieren von neuen Instanzen wird durch die Automatisierung einfacher. Das bedeutet, dass kein dedizierter Personenkreis benötigt wird um die Application-Server hoch zu skalieren. Womit ich auf keinen Fall Admins als überflüssig erachte! Die können sich aber auf wichtige Dinge konzentrieren, statt Arbeit zu erledigen, die man auch einem Äffchen trainieren könnte. Nehmen wir einfach folgendes an. Der einzige Admin, der die Infrastruktur aufsetzen kann, ist vor dem Black Friday krank. Es müssen aber unbedingt noch mehr Application-Server. In unserem Szenario kein Problem. Im Endeffekt kann jeder(tm) einen Heat-Stack mit Application-Servern daneben stellen. Sicherlich gilt hier Faktoren wie die maximale Anzahl an Verbindungen auf dem DBMS zu beachten. Aber das führt hier zu weit.

Wie auch für das Beispiel des Black Fridays, kann ein neues Release der Applikation durch einen zusätzlichen Heat-Stack ausgerollt werden. Dabei werden einfach neue Instanzen mit der neuen Version gestartet und die alten einfach abgeschaltet.

Genau an dieser Stelle kommt häufig die Frage: Wie hilft uns Heat bei einer Datenmigration?

Wie hilft uns Heat bei einer Datenmigration? #

(Wobei als Datenmigration auf Nachfrage immer eine Änderung des SQL-Schemas war.)

Also… Heat bzw. jedes andere Orchestrationtool hilft in erster Linie genau gar nicht. Zu erst einmal sollte man wissen, dass ein ALTER TABLE in den meisten DBMS nicht um sonst ist (siehe z.B. Avoiding MySQL ALTER table downtime, Schema changes – what’s new in MySQL 5.6?). Gerade wenn eine Tabelle groß wird, sollte man wirklich einen geeigneten Migrations-Plan haben!

Auf jeden Fall gehört eine Migration nicht in den Code (schon gar nicht in den Startup-Code) eines neuen Releases! Keiner möchte eine Situation haben, in der ein neues Release installiert wird und gleich die laufende Production-Umgebung mit den Abgrund zieht (z.B. durch einen expliziten Lock durch ein ALTER TABLE). Die einfachste Möglichkeit Schema-Änderungen zu verhindern ist wohl IKEA Kloppe. Einfach mal damit bei dem entsprechenden Entwickler vorbeischauen.

Neben den möglichen Problemen bei einem ALTER TABLE, kann die vorherige Version der Applikation (App-1.0) mit dem neuen Schema nichts anfangen und daher in Fehler laufen. Im besten Falle hält man die Schema-Änderungen so klein, dass genau dies nicht passiert. Ein zusätzliches Feld wird einem ORM z.B. noch nicht weh tun. Ein Feld entfernen wird man dagegen erst wirklich wenn es nur noch Applikationen gibt, die ohne dieses Feld auskommen.

In jedem Fall sollte mit versionierten DB-Schemata gearbeitet werden, so dass App-2.0 auch mit dem Schema von App-1.0 arbeiten kann, dafür aber ggf. Features noch nicht freigeschaltet sind.

Bleibt die zu vermeidende Situation: Man benötigt ganz ganz ganhanz dringend ein anderes Schema und bricht dadurch App-1.0. Hier gilt es App-2.0 erst einmal überall auszurollen. Ggf. zuerst einmal mit reduziertem Feature-Set. Natürlich wird App-2.0 ohne Migration der DB an genau der selben Stelle fehlschlagen wie auch App-1.0. Doch lässt sich hier gezielt das neue Schema probieren, die Exception fangen und auf das alte Schema zurückfallen.

Vollautomatisierung hilft #

Natürlich stimmt meine Aussage von oben nicht. Orchestration und Vollautomatisierung hilft sehr wohl. Zwar gehört die Logik für dem Umgang mit Migrationen in die Applikation, also in den Kompetenzbereich der Entwickler, doch nicht die Migration selbst. Die Vollautomatisierung hilft einfach und schnell ein komplettes Setup aufzubauen und die Migration immer und immer wieder zu testen, so lange bis das Zero-Downtime-Deployment funktioniert. Ist die Änderung doch zu groß um diese ohne Downtime durchzuführen, kann wenigstens der zu erwartende Zeitraum abgeschätzt werden und entsprechende Maßnahmen treffen.