© Bruce Rolff, 123RF

Ihrem eigenen Release-Gesetz folgend verabreichten die Open-Stack-Entwickler im Oktober der Cloudwelt mit ihrer neuen Version auch neue Impulse. Neben diversen Fehlerkorrekturen implementierten sie in den Kernkomponenten auch Neuerungen, die zu bewerten sich dieser Artikel zur Aufgabe macht.

Das Open-Stack-Projekt, dessen Ziel ein umfassender Cloudkosmos auf der Basis von Open-Source-Software ist, stellte im Oktober planmäßig die neue Version seiner Lösung vor. Die mittlerweile 14. Open-Stack-Release, die auf den Codenamen Newton [1] hört, bringt Verbesserungen in vielerlei Hinsicht: Neben höherer Skalierbarkeit und neuen Sicherheitsfunktionen beseitigt sie auch viele Fehler, die Admins in vorangegangenen Versionen das Leben erschwerten. Das Linux-Magazin hat sich die neue Umgebung näher angeschaut.

Das große Zelt

Schon beim ersten Blick ins Changelog der neuen Release fällt ein wesentlicher Unterschied zu vorangegangenen Open-Stack-Versionen auf: Über 20 Dienste haben eigene Einträge in den Release Notes von Open Stack. Das ist vor allem auf die Big-Tent-Initiative zurückzuführen, die die Open-Stack-Foundation vor anderthalb Jahren ins Leben rief: Bis zu diesem Zeitpunkt war die Bezeichnung Open Stack für die Kernkomponenten reserviert, also jene Basis an Diensten, die für grundlegende Cloudfunktionalität unbedingt nötig sind.

Teil dieser Sammlung konnten neue Open-Stack-Komponenten nur dann werden, wenn sie erfolgreich durch den Incubator-Prozess gekommen waren und genügend Mitglieder des Technical Board der Open-Stack-Foundation dafür stimmten, jene Komponente als Kernkomponente zu akzeptieren.

Nach Meinung der Foundation war diese Lösung nicht zeitgemäß, denn sie könnte – so die damalige Erklärung – Innovationen verhindern. Aus dieser Erkenntnis heraus entstand die Big-Tent-Initiative: Seither gelten wesentlich weniger strenge Regeln für Komponenten, die Teil von Open Stack sein wollen. Offenbar mit Erfolg: Insgesamt 32 Komponenten haben die Entwickler im Zuge von Open Stack Newton offiziell freigegeben. Hinzu kommen noch diverse Python-Bibliotheken der Oslo-Gruppe [2], die viele Open-Stack-Komponenten unter der Haube benutzen. Schon auf den ersten Blick ist damit klar: Open Stack Newton bietet mehr Funktionalität als jede Vorgänger-Release in der Open-Stack-Geschichte.

Der harte Kern

Es bietet ich trotzdem an, zunächst den harten Kern von Open Stack Newton zu betrachten. Denn der existiert trotz Big-Tent-Initiative natürlich weiterhin: Nach wie vor genügen die Komponenten Keystone, Neutron, Glance, Cinder und Nova, um auf einem Cluster aus mehreren Servern eine funktionierende Open-Stack-Umgebung zu betreiben, die virtuelle Maschinen starten, stoppen und verwalten kann.

Den Anfang macht Keystone, das für die Benutzerverwaltung zuständig ist und sich um Autorisierung wie Authentifizierung kümmert: Dort ist das API für Domains nun als stabil markiert, sodass Admins und externe Projekte es auch offiziell einbinden können. Domains sind eine weitere Ebene im Keystone-Rechtemodell, um die Berechtigungen für einzelne Benutzer und Projekte noch feiner abzustufen.

Komplett überarbeitet haben die Entwickler auch die Installation und das Upgrade von Keystone: Bislang war es nötig, in »keystone.conf« ein permanentes Passwort zu setzen, das den Zugriff auf die Admin-Rolle ermöglichte und so eine Art Generalschlüssel für Keystone war. Anders war es gar nicht erst möglich, Keystone mit den nötigen Accounts für die eigenen Dienste in Open Stack zu bestücken. Die neue Installationsroutine von Keystone erlaubt es, kein Admin-Passwort in der Datei »keystone.conf« zu setzen – und trägt so zur Sicherheit der Lösung bei.

Apropos Sicherheit: Die Entwickler haben insbesondere am Caching-Mechanismus von Keystone geschraubt und so mehrere Codestellen beseitigt, die vorher das Abfangen von Tokens aus Caches ermöglichten. Login-Daten speichert Keystone nun verschlüsselt ab, was verhindert, Credentials aus der Keystone-Datenbank einfach im Klartext auszulesen.

Wenig Glanz bei Glance

Nicht besonders augenfällig sind die Änderungen bei Glance: Außer Verbesserungen bei den unterstützten Speicherdiensten zur Ablage von Images und außer neuen Formaten hat sich beim Image-Dienst wenig getan. Eine auf den Namen Glare getaufte Funktion ist jedoch erwähnenswert: Glare (Glance Artifact Repository) bietet die Möglichkeit, auch beliebige andere Inhalte in Glance abzulegen – eben Artifacts.

Ein praktisches Beispiel dafür sind binäre Dateien, die zwar keine VM-Abbilder sind, von Nutzern innerhalb der Cloud aber trotzdem herunterladbar sein sollen. Heat oder Murano, zwei weitere Open-Stack-Dienste, kommen so über Glance an Dateien, die sie andernfalls von irgendwo herunterladen müssten.

Ganz neu ist Glare allerdings nicht, die Funktionalität war in der Version 3 des API von Glance bereits vorgesehen. In Newton haben die Entwickler sich nun aber dazu durchgerungen, aus Glare einen eigenständigen Dienst zu machen, der vollkommen unabhängig von den Glance-Diensten – Glance-API und Glance-Registry – läuft.

Außerdem wichtig: Das Glance-API in Version 1 gilt nun offiziell als obsolet und wird wohl in der übernächsten Release aus Open Stack verschwinden. Diverse externe Tools nutzen jedoch noch das API der ersten Version, obwohl das API in Version 2.0 bereits seit einiger Zeit in Glance verfügbar ist. Wer solche Dritthersteller-Tools für die Arbeit mit Open Stack nutzt, sollte also möglichst bald überprüfen, ob diese auch mit der Version 2 des API von Glance bereits umzugehen vermögen.

Neutron profitiert von beschleunigter Entwicklung

Ein ganzes Füllhorn von Änderungen ergießt sich hingegen über Neutron, die SDN-Komponente von Open Stack. Wobei der Anwender hier differenzieren sollte: Die meisten der Änderungen betreffen die Open-Vswitch-Implementation in Neutron. Wer Neutron also mit dem SDN-Plugin eines anderen Herstellers kombiniert, bekommt von diesen Änderungen nicht viel mit.

Wer jedoch auf die interne Open-Vswitch-Implementation von Neutron setzt, der darf sich auf viele Neuerungen freuen: Der Layer-3-Agent für Open Vswitch, der für VMs die externe Konnektivität herstellt, hat nun eine Schnittstelle für Erweiterungen. Durch die lassen sich beim Layer-3-Agent künftig wie auch beim Layer-2-Agent für Open Vswitch zusätzliche Funktionen nachrüsten.

Per Quality-of Service-Regel lässt sich für Open-Vswitch-Ports künftig festlegen, dass dem Port eine bestimmte Bandbreite mindestens zur Verfügung stehen muss. Und auch an den Interna haben die Entwickler geschraubt: Während die L2- und L3-Agents für Open Vswitch bisher die Kommandos »ovs-ofctl« und »ovs-vsctl« aufriefen, setzen sie künftig auf die dafür in Open Vswitch ohnehin vorgesehene Python-Bibliotheken. Die Neutron-Entwickler sind der Meinung, dies sorge für bessere Stabilität und bessere Performance.

Obendrein haben die Neutron-Entwickler eine seit Langem gehegte Forderung der Nutzer umgesetzt: Virtuelle Maschinen dürfen künftig ohne IP-Adresse starten – der Anwender muss also nicht schon beim Anlegen der VM definieren, zu welchem virtuellen Netz diese gehört. Stattdessen lässt sich das Netzwerksetup als separater Prozess auch nach dem Start der VM noch erledigen.

Besonders für die Integration einer Open-Stack-Cloud in bereits vorhandene konventionelle Setups ist ein Feature interessant, das die Entwickler als VLAN-aware VMs bezeichnen: Dabei lässt sich eine virtuelle Maschine direkt mit einem spezifischen Interface auf dem Host verbinden, das selbst Teil eines vorhandenen VLAN-Netzwerks ist.

Dieses Konstrukt dient besonders in jenen Fällen als Krücke, in denen die Verbindung zwischen einer bislang genutzten althergebrachten Welt und einem neuen virtuellen Netz in Open Stack notwendig ist. Gerade bei privaten Clouds im Aufbau ist dieses Szenario ein recht häufiges Problem – die Hersteller verschiedener kommerzieller SDN-Konfigurationen haben daher vergleichbare Features bereits länger im Angebot. Die offizielle Open-Vswitch-Umsetzung von Open Stack zieht nun also auch damit gleich.

Treiberupdates für Cinder

Der Open-Stack-Dienst für persistenten Blockspeicher, Cinder, setzt in Newton einen Trend der vergangenen Jahre fort: Ähnlich wie Neutron ist auch Cinder ein API, dessen Funktionalität im Wesentlichen Plugins realisieren. Der Standardtreiber basiert auf I-SCSI und LVM und ist für die meisten Setups irrelevant – herstellerspezifische Plugins geben bei Cinder den Ton an.

Entsprechend umfangreich ist die Liste an Updates für bestehende Cinder-Treiber: Die Netapp-NFS- und Netappp-CDOT-Treiber haben die Entwickler genauso überarbeitet wie jenen für IBMs Flashsystem oder den für Nexenta Edge. Auch die Unterstützung für EMCs Vmax ist nun im Vergleich zur Vorversion deutlich besser. Hinzu gekommen sind Treiber für Freestor von Falconstor, Fusionstorage von Huawei, I-SCSI-Laufwerke von Synology-Geräten sowie von ZTE.

Besonderes Augenmerk legten die Entwickler auf ein Feature mit dem etwas sperrigen Namen HA A-A: Gemeint ist High Availability mit Active-Active-Support, also Storage-Backends, die im Hintergrund auf denselben Backend-Speicher zugreifen, in Cinder jedoch separat über mehrere Wege angesprochen werden. Grundsätzlich ist diese Funktion nun in Newton Cinder vorhanden.

Doch die Entwickler warnen davor, sie bereits in der Produktion zu nutzen: Diverse Stabilisierungen seien nötig, und im Augenblick handele es sich um Work in Progress. Es ist davon auszugehen, dass der große Teil der Active-Active-Funktionalität erst in der nächsten Open-Stack-Version, Ocata, produktionsreif bereitstehen wird.

Bereits jetzt lässt sich die Retype-Funktionalität für virtuelle Blockgeräte nutzen: Diese wandelt auf Wunsch ein verschlüsseltes Volume in ein unverschlüsseltes um – und vice versa. Wer Volumes löschen will, für die auch Snapshots existieren, erspart sich künftig außerdem die bisher notwendige Klickorgie: Dank Cascade-Funktion lässt sich das nun in einem Arbeitsschritt erledigen.

Das Urgestein: Nova

Als Keimzelle von Open Stack gilt allgemein Nova, also jene Komponente, die bis heute für die Verwaltung von virtuellen Maschinen in Open Stack verantwortlich ist. Der Dienst ist im Open-Stack-Ensemble mit Abstand der wichtigste – und folgerichtig bringt er in Newton auch die meisten neuen Funktionen mit. Erheblich erleichtert haben die Entwickler etwa den Start neuer VMs: Neben der bereits erwähnten Möglichkeit, eine VM zwar mit einer virtuellen Netzwerkkarte, aber ohne IP zu starten, kann der Nutzer das Anlegen virtueller Netze (Abbildung 1) auch ganz Nova überlassen.

Abbildung 1: Beim Anlegen virtueller Netzwerk-Topologien stellt Newton nun weniger Fragen und erzwingt bei verbliebenen Fragen eindeutigere Antworten.

Bisher war es ein langwieriger Prozess: Nach dem Anlegen des virtuellen Netzes musste der Nutzer, wenn die VMs Verbindung zum Internet haben sollten, auch einen Router händisch anlegen und ihn mit dem virtuellen Netz verbinden. Wer sich nicht ohnehin mit Open Stack auskennt, ist damit selbst dann noch überfordert, wenn das Open-Stack-Dashboard (Horizon) als GUI hilft.

Künftig kann der Nutzer beim Starten der VM angeben, dass Nova sich um das Thema Netzwerk kümmern soll. Die vormals beschriebenen Schritte führt Nova dann automatisch durch, sodass der Nutzer am Ende des Vorgangs über eine laufende VM mit Netzwerk und Verbindung zum Internet verfügt.

Änderungen gibt es auch bei den Cells: Darunter versteht Nova spezielle Kategorien, nach denen sich Rechenzentren sortieren und zusammenfassen lassen. Diese Cells sind separat ansprechbar, um etwa eine VM in einer speziellen Zelle zu starten. Cells in der Version 2 gehören schon seit einiger Zeit zu Nova. In der Newton-Release erklären die Entwickler das Feature allerdings für fertig, weil die komplette Cells-V2-Spezifikation in Newton erstmals umgesetzt ist.

Aufgebohrt haben die Nova-Entwickler zudem das Placement-API. Gemeint ist ein eigener Teil des Nova-API, mit dem Nutzer das Placement von VMs von außen aktiv beeinflussen können. Grundsätzlich nimmt Nova dem Nutzer diese Arbeit zwar ab: Wenn dieser lediglich eine VM haben möchte, sucht der Nova-Scheduler automatisch nach einem passenden Host für sie.

Das Placement-API räumt dem Anwender hingegen ein Mitspracherecht ein: Mittels eines speziellen Nova-Kommandos legt er Placement-Regeln an und kann beim Starten von VMs auch auf diese verweisen. Voraussetzung dafür ist allerdings, dass der Admin das Feature per Policy-Einstellung freigegeben hat.

Bessere User Experience bei Horizon

Das bereits erwähnte Open-Stack-Dashboard Horizon hat sich in Newton vorrangig unter der Haube verändert. Diverse Umbauten sollen beim Anwender eine angenehmere Nutzungserfahrung bewirken: Wesentlich strikter geht Horizon in Newton etwa mit den Eingabefeldern für die Netzwerkkonfiguration um, die Anwender bisher zwangsweise im ersten Schritt absolvieren mussten, um überhaupt zu einer lauffähigen VM zu kommen.

Beim Anlegen des virtuellen Netzes konnten Anwender in die vorgegebenen Felder praktisch eintragen, was sie wollten: Horizon akzeptierte alle Werte klaglos. Damit ist nun Schluss: Gerade beim Netz kontrolliert Horizon die Eingaben des Anwenders künftig deutlich genauer (Abbildung 2).

Abbildung 2: Im Feld für den Netzwerknamen hat der Admin noch immer die Wahl. Beim Festlegen der Netzwerk-Details (Adresse, DNS-Server) gelten ab sofort aber rigorose Vorgaben.

Auch für die Admins der Cloud bringt Horizon in Open Stack Newton neue Funktionen: Eine ganze Reihe zusätzlicher Parameter etwa steht bereit, um das Verhalten von Horizon zu beeinflussen. So lässt sich nun etwa feiner festlegen, welche Operationen Nutzer im Dashboard überhaupt ausführen können und welche es ihnen gar nicht erst zeigt. Ferner ist es möglich, Horizon ab sofort ausschließlich als Frontend für Open Stack Swift zu benutzen – den Objektspeicher der Cloudumgebung. Bislang bestand Horizon mindestens auch auf Nova, um zu funktionieren.

Neuigkeiten in Sachen Container

Das Thema Container wird für Open Stack wichtiger. Das war auch beim Open Stack Summit in Barcelona im Oktober deutlich zu erkennen, viele Vorträge kreisten um die Themen Docker und Kubernetes. Doch während es bei Konferenzvorträgen meist um den Blick in die Zukunft geht, liefert die Newton-Release auch handfeste Container-Funktionalität, die sofort bereitsteht: In Form von Magnum, Kolla und Kuryr widmen sich gleich drei Open-Stack-Dienste verschiedenen Container-Aspekten.

Magnum (Abbildung 3) etwa hat das Linux-Magazin in einem separaten Artikel [3] bereits ausführlich vorgestellt. Der Dienst ermöglicht es, Container in VMs auf der Cloud zu starten und diese von außen – also über die Open-Stack-APIs – zu steuern. In Newton liefern die Entwickler ausführlichen Support für die so genannten Container Orchestration Engines (COE) nach: Künftig lassen sich mit Magnum also auch Docker Swarm, Kubernetes und Mesos nutzen.

Abbildung 3: Magnum kann in Open Stack Newton nun auch Container-Cluster, zum Beispiel mit Hilfe von Kubernetes oder Swarm, verwalten.

Ebenfalls haben die Magnum-Entwickler den Bare-Metal-Support von Magnum weiter ausgebaut, sodass sich Hardware-Knoten in Kubernetes integrieren lassen. Überhaupt spielt das Thema Bare-Metal-Deployment in Newton eine große Rolle; dieser Artikel nimmt sich dieses Aspekts später noch im Detail an.

Schritte in eine andere Richtung geht Kolla: Hier stehen nicht die Container der Nutzer im Vordergrund. Ziel ist es viel mehr, Open-Stack-Komponenten selbst in Form von Containern auszuliefern. Kombiniert mit entsprechenden Werkzeugen soll so die Open-Stack-Installation selbst deutlich leichter zu warten sein, als es bei typischen Deployment-Szenarien auf Basis von Puppet oder Ansible der Fall ist. In Newton macht Kolla einen großen Satz nach vorne: Tatsächlich lassen sich mit dem Dienst ab sofort nämlich Open-Stack-Container auf echtem Blech ausrollen. Zuvor konnte Kolla lediglich Open Stack als Container in virtuellen Maschinen bieten.

Bis zum blanken Metall

Viele Anbieter wollen Open Stack nicht nur nutzen, um für Kunden VMs oder Container in VMs auszurollen. Das Thema Bare Metal spielt eine zunehmend wichtige Rolle: Kunden können bei Bedarf dann ganze physische Server für sich beanspruchen, ohne auf die Open-Stack-Vorteile wie fertige Abbilder für die gängigen Betriebssysteme oder Orchestrierung zu verzichten.

Einen Haken hat die Sache: Während ein KVM-Hypervisor durch »nova-compute« vollständig zu verwalten ist, kommen bei echten Servern Aspekte wie klassisches Out-of-Band-Management (etwa per IPMI) hinzu. Ironic (Abbildung 4) heißt der Open-Stack-Dienst, der aus einem nackten Server einen Server macht, den ein Open-Stack-Kunde per Open-Stack-API für sich beanspruchen kann.

Abbildung 4: Ironic ist die Open-Stack-Komponente für Bare-Metal-Deployments, die in Newton das Nutzen mehr als eines Netzwerks erlaubt.

Im Gegensatz zu KVM-basierten Setups haften einige Einschränkungen an Ironic und den durch Ironic installierten Servern. Ein großer Nachteil war bisher etwa die Tatsache, dass Multi-Tenant-Netzwerke mit Ironic unmöglich waren. Mehrere Kunden konnten also Ironic nutzen, mussten sich allerdings damit abfinden, dass sich die jeweiligen Hosts im selben physischen Netz befanden und echte Traffic-Trennung fehlte. Sicherheitsbeauftragten war an dieser Stelle verständlicherweise sehr unwohl.

Newton sorgt jedoch für Abhilfe: Multi-Tenant-Networking gehört ab jetzt zum Funktionsumfang von Ironic. Obendrein haben die Entwickler an der Ironic-Rechteverwaltung geschraubt: Künftig ist es – wie bei anderen Open-Stack-Diensten seit Langem – möglich, Berechtigungen für einzelne Aktionen fein abgestuft zu vergeben. Bisher bestand lediglich die Option, die jeweiligen Funktionen ganz an- oder auszuschalten.

Schnell übersehen: Open Stack Swift

Swift ist die zweite Hälfte der Open-Stack-Keimzelle neben Nova, der Objektspeicher war der Rackspace-Beitrag zu den ersten Open-Stack-Versionen. Um so verwunderlicher ist, dass der Dienst in vielen Open-Stack-Installationen fehlt – etwa weil stattdessen Ceph mit seinem Rados-Gateway zum Einsatz kommt. Swift bietet für Open-Stack-Installationen einen Objektspeicher nach dem Vorbild von Amazons S3 auf Basis eines eigenen Protokolls (Swift). Für Newton haben sich die Swift-Entwickler einige Funktionen ausgedacht, die den Dienst deutlich attraktiver gestalten.

Ab sofort beherrscht Swift versionierte Objekte: Von einem Objekt können also mehrere Versionen von unterschiedlichen Zeitpunkten existieren; im Grunde handelt es sich um Snapshots. Der Admin wählt aus, welche Versionen des Objekts er behalten will und welche er löschen möchte. Wer die Funktion nicht braucht, darf Swift aber auch so konfigurieren, dass wie bisher nur die aktuelle Version im Cluster existiert.

In Sachen Sicherheit kommen bei Swift verschlüsselte Objekte hinzu: Wenn der Admin seinen Swift-Cluster entsprechend konfiguriert, legt dieser die eingehenden Objekte automatisch verschlüsselt auf seinen Festplatten ab. Zur Nutzerseite hin ist die Funktion nicht exponiert: Der Anwender kann also nicht etwa per Restful-Request für einzelne Objekte festlegen, dass sie im Klartext oder verschlüsselt abzulegen sind.

Entsprechend sorgt die Verschlüsselung der Objekte in Swift auch nicht für hundertprozentigen Datenschutz – sie verhindert aber, dass sich die abgelegten Inhalte allzu leicht auslesen lassen. Wer ganz sicher sein will, kommt aber um eine echte Ende-zu-Ende-Verschlüsselung nicht herum.

Schließlich haben die Swift-Developer sich auch des Themas Performance in Newton angenommen: Eine große Zahl von Objekten wird Swift künftig dank des Concurrent-Bulk-Delete-Feature schneller löschen als bisher.

Und sonst so?

Viele weitere kleine und große Veränderungen erleichtern Admins und Nutzern die Verwendung von Open Stack Newton. Heat, das Orchestrierungswerkzeug von Open Stack (Abbildung 5), lässt sich künftig etwa an externe DNS-Server koppeln. Das ist für die Kooperation mit Kolla und anderen Bare-Metal-Diensten relevant: Beim Ausrollen von ganzen Open-Stack-Clustern mit Heat war bislang ein DNS-Server stets Teil des Template. Ab sofort lässt sich Heat an vorhandene DNS-Server anschließen.

Abbildung 5: Die Orchestrierungskomponente Heat kann in Newton externe DNS-Server nutzen, was besonders Bare-Metal-Deployments nützt.

Auch nicht zu vergessen ist Ceilometer: Der Dienst sammelt in Open Stack Telemetrie-Daten der verschiedenen Open-Stack-Komponenten ein und bildet so die Grundlage für Verrechnungssysteme. Ceilometer hat eine wechselvolle Geschichte hinter sich: Ursprünglich loggte der Dienst seine Daten in dieselbe Datenbank, in der bei Open Stack die Metadaten der Dienste liegen – in fast allen Fällen also MySQL.

MySQL ist naturgemäß für Streams von Zeitserien ungeeignet. Kurzerhand entschloss man sich, in Form von Gnocchi eine eigene Time-Series Database (TSDB) für Ceilometer zu entwickeln. Das hat nach einigen Anläufen geklappt, mittlerweile steht Gnocci bereit. In Newton bohren die Entwickler die Storage-Backends von Ceilometer entsprechend auf. Ein eigenes Gnocchi-Backend ermöglicht es künftig, Daten aus Ceilometer direkt in Gnocchi abzulegen.

Tests und Standardisierung

Auch fernab von den Open-Stack-Komponenten zeigen sich Veränderungen: Rally liefert dafür ein gutes Beispiel. Mit Rally ist ein Benchmark-Tool am Start, das diverse Tests standardisiert durchführt und die Ergebnisse aufbereitet ausgibt. Damit gelingt es, verschiedene Open-Stack-Angebote automatisiert zu vergleichen.

Im Vergleich zur Mitaka-Version von Rally unterstützt Rally in Newton nun diverse neue Plugins, um mehr Open-Stack-Funktionen zu testen, und lässt sich deutlich besser an Tempest ankoppeln – den Dienst, der bei vorhandenen Open-Stack-Clouds automatisch API-Kompatibilitätstests durchführt. Zudem generiert Rally nun auf Wunsch Trend- und Statistikanzeigen und wird so zum kleinen Trending-Tool, das zumindest einen ungefähren Überblick über die Performance-Entwicklung der Cloud liefert.

Fazit

Was bereits bei früheren Open-Stack-Versionen erkennbar war, setzt sich in Newton fort: Epochale Änderungen durchläuft Open Stack zumindest derzeit nicht mehr. Stattdessen steht nun das Feintuning an allen Ecken und Enden an. Open Stack Newton erhält deshalb eine klare Empfehlung, Admins sollten darüber nachdenken, wie sie ihre Open-Stack-Umgebungen aktualisieren. (jcb)