Blog von Betacloud

Get rid of ubuntu-xenial-16.04-cloudimg-console.log

When using the Vagrantbox ubuntu/xenial64 you will have a file ubuntu-xenial-16.04-cloudimg-console.log after the start. If you do not need it simply add the following lines to your Vagrantfile to get rid of it.

Source: https://groups.google.com/forum/#!topic/vagrant-up/eZljy-bddoI

Wahl eines zukunftssicheren Deploymentframeworks: Projekt Tags

Mit Einführung der Mirantis Cloud Platform (MCP) und Abkündigung von Mirantis OpenStack (MOS) hat Mirantis einen Grossteil seiner Entwickler von Fuel, dem zugrundeliegendem Projekt von Mirantis OpenStack (MOS) abgezogen und damit das Projekt in eine unbekannte und unsichere Zukunft geschickt.

Als eine der Konsequenzen ist seit Ende Juni Fuel kein offizielles OpenStack Projekt mehr.

Das „no vendor lock-in“ in den Slogans von Mirantis bezieht sich wohl nicht auf sie selbst. Jeder der auf Fuel als ein offenes Deploymentframework für OpenStack gesetzt hat, hat nun definitiv ein Problem.

In diesem sowie folgenden Artikeln werden Anhaltspunkte beschrieben welche bei der Auswahl eines möglichst zukunftssicherem Deploymentframeworks für OpenStack helfen können.

Projekt Tags

Vom technischen Komitee von OpenStack werden Projekten sogenannte Tags zugewiesen. Eine Übersicht aller existierenden Tags findet sich auf governance.openstack.org. Für eine Zuweisung müssen die in der Dokumentation zum jeweiligen Tag aufgeführten Anforderungen erfüllt werden.

Das Tag team:diverse-affiliation wird an Projekte vergeben bei denen die aktiven Entwickler von einer Vielzahl unterschiedlicher Organisationen stammt, insgesamt also eine hohe Diversität vorliegt. Im Detail darf keine beteiligte Organisation mehr als 50% aller Commits erstellt haben und zwei Organisationen zusammen dürfen nicht mehr als 80% aller Commits erstellt haben. Auch die Zusammensetzung der Core Reviewer und die durchgeführten Reviews werden berücksichtigt. Kolla, das Deploymentframework auf dem der OpenStack Infrastructure & Service Manager (OSISM) basiert, wurde dieses Tag zugewiesen.

Mit Vorsicht zu geniessen sind OpenStack Projekte mit dem Tag team:single-vendor. Dieser Tag teilt mit, dass ein Projekt hauptsächlich von einer einzigen Organisation gestemmt wird. Fuel war dieses Tag zugewiesen gewesen. Den OpenStack Projekten „TripleO“ (RedHat OpenStack Platform von RedHat) sowie den „Juju Charms“ (BootStack von Canonical) ist dieses Tag ebenfalls zugewiesen worden. Das „Chef OpenStack“ Projekt ist langsam reif für dieses Tag und es ist nur noch eine Frage der Zeit bis die Zuweisung erfolgen wird.

Überprüfung von Keystone Federation Mappings

Keystone Federation Mappings können über das in keystone-manage enthaltene Kommando mapping_engine getestet werden. Dafür wird eine Datei, etwa testdata, mit Testdaten erstellt. Beispielsweise mit folgendem Inhalt:

Anschliessend kann dann das Mapping mittels keystone-managed mapping_engine --rules rules.json --input testdata getestet werden.

Vagrant: Too many open files

Bei Nutzung von Vagrant unter MacOS kommt es beim Start von neuen virtuellen Systemen häufig zu der Fehlermeldung ...vagrant/util/safe_chdir.rb:25:in `chdir': Too many open files - getcwd (Errno::EMFILE). Durch Erhöhung des Limits mit ulimit -n 4096 lässt sich dieser Fehler einfach beheben.

Ansible Modul „test-infrastructure“

Auf GitHub stehen einige von uns entwickelte und eingesetzte Ansible Module zur Verfügung. In diesem Beitrag wird das Ansible Modul test-infrastructure vorgestellt.

In unserer auf Jenkins basierenden CI Umgebung testen wir unterschiedliche Konfigurationsszenarien von OpenStack. Für einige dieser Szenarien sind die im Kolla Projekt verfügbaren Ansible Rollen und Docker Images nicht ausreichend und auch gar nicht erforderlich.

Beispielsweise ist das dann der Fall, wenn die Integration des Identity Service „Keystone“ mit LDAP getestet, im Block Storage Service „Cinder“ als zusätzliches Storage Backend ein NFS Export eingebunden oder ein Amazon S3 kompatibler Object Storage für Backups von Volumes genutzt werden soll.

Um die für diese Szenarien benötigten zusätzlichen Dienste während der Tests bereitstellen zu können haben wir das Ansible Module test-infrastructure erstellt.

Es stellt derzeitig einen OpenLDAP Server mit phpLDAPAdmin, einen NFS Server und eine Docker Registry vorkonfiguriert und bereits initialisiert, beispielsweise mit LDAP Benutzern und Gruppen oder NFS Exports, auf Basis von Docker zur Verfügung.

Error response from daemon: maximum retry count cannot be used with restart policy ‚unless-stopped‘

Hat man eine OpenStack Umgebung mit Kolla <= 3.0.2 und Docker < 1.13 ausgerollt und anschliessend Docker auf eine Version >= 1.13 aktualisiert kommt es beim Start von Containern zu dem folgendem Fehler: Error response from daemon: maximum retry count cannot be used with restart policy 'unless-stopped'

Verursacht wird dieser Fehler durch eine Änderung in der Docker API v1.25. Der MaximumRetryCount, von Kolla <= 3.0.2 per Default auf den Wert 10 gesetzt, ist nun nicht mehr gültig und müsste auf 0 gesetzt sein.

In Kolla wurde dieses Problem mittlerweile behoben und in allen aktuellen Versionen wird MaximumRetryCount nicht mehr gesetzt wenn die Restart Policy unless-stopped verwendet wird. Eine gute Übersicht über die einzelnen Restart Policies findet sich im Blog von Codeship.

Probleme treten nun auf wenn man die Docker Engine auf einem Konten einer bestehenden Kolla Umgebung auf eine Version >= 1.13 aktualisiert.

Auf Stackoverflow findet sich dazu der Hinweis eine mögliche Lösung ist die direkte Bearbeitung der hostconfig.json Datei eines Containers, abgelegt im entsprechendem Verzeichnis unter /var/lib/docker/containers, gefolgt von einem Restart des Docker Services.

Mittlerweile wurde das docker update Kommando eingeführt, mit dem sich einige Parameter eines bereits erstellten Containers bearbeiten lassen. Darunter auch die zu nutzende Restart Policy.

Erfreulicherweise wird beim setzen der unless-stopped Restart Policy, für einen Container der diese Restart Policy bereits gesetzt hat, der Wert für MaximumRetryCount auf 0 gesetzt. Anschliessend ist ein Start des Containers wieder möglich.

Create a copy of a Docker volume

Quick & dirty twoliner to create a copy of a Docker volume.

Stopp eines nicht vorhandenen Dienstes

Manchmal möchte man mit einer Ansible Rolle einen Dienst stoppen, der nicht auf allen geplanten Umgebungen vorhanden ist. Um nicht vorab eine grössere Anzahl von Vorabprüfungen einzuführen lässt sich folgender Workaround verwenden. Dadurch schlägt der Task dann nicht mehr fehl wenn der zu stoppende Dienst nicht gefunden wurde.