Mehr oder weniger Verwirrung für Anwender?
Das OpenStack-Modell "Big Tent"
Früher war bei OpenStack von "Core"-Projekten die Rede, welche die offene Cloud-Umgebung ausmachen. In den nur fünf Jahren OpenStack ist dieser technische Kern nicht nur an Programmierzeilen, sondern auch an Projekten geradezu rasant gewachsen. Aus dem Core wurden dabei die "integrierten" Projekte, die Bestandteil der halbjährlichen Release-Freigaben sind. Künftig gibt es neben diesen Kernprojekten eine Reihe weiterer, die unter dem Dach der OpenStack Foundation zur Kategorie "Big Tent" zählen. Was bedeutet das für OpenStack?
Eine kurze Erläuterung zum neuen Verfahren: Auch künftig wird es sogenannte DefCore-Projekte geben. Diese gehören nach Definition der Foundation zum unverzichtbaren Kern von OpenStack, sind ausgereift und weit verbreitet. Dazu gehören die Projekte Nova (Compute), Swift (Storage), Glance (Image), Horizon (Dashboard), Neutron (Network) und Keystone (Identity). Nicht dazu gehören - obschon sie zum letzten "integrated" OpenStack-Release Kilo gehören - die Module Heat (Orchestration), Ironic (Bare Metal Service), Trove (Database) und Ceilometer (Metering). Diese fallen künftig in die Kategorie "Big Tent".
- Vorteile von OpenStack
Die wichtigsten Argumente für Openstack laut einer Crisp-Studie sind die Offenheit der Technologieplattform, Flexibilität und die Chance, Kosten zu senken. - Unterstützer
Zahlreihe namhafte Unternehmen und Organisationen unterstützen Openstack. - Releases
Überblick über die Openstack-Releases: Im Laufe der Zeit nahm die Anzahl der Komponenten zu. - Im Wachstum
Openstack ist hauptsächlich in Python und Java geschrieben. Die Grafik zeigt den steigenden Codeumfang im Laufe der Zeit. - Aufbau
Die Architektur von Openstack ist recht komplex. - Funktionsbausteine
Die wichtigsten Komponenten von Openstack. - Übersichtlich
Das Horizon Dashboard bietet ein benutzerfreundliches Webinterface zur Verwaltung der eigenen Cloud. - Architektur
Die Red Hat Enterprise OpenStack Plattform im Detail.
Welche Ziele sollen erreicht werden?
Die Community möchte damit mehreren Problemen begegnen. Es sollen konkurrierende Projekte bestehen, die unterschiedliche Ansätze verfolgen oder andere funktionale Schwerpunkte setzen. Die Projekte Stacktach und Monasca bieten einen ähnlichen Funktionsumfang wie Ceilometer, aber das Technical Committee von OpenStack musste bisher auf das "offizielle" Projekt Ceilometer verweisen. Das beschränkt die Entwicklung eines Ökosystems und behindert letztlich die Verbreitung von OpenStack am Markt. Ähnlich ist es mit dem Deployment-Tool TripleO, zu dem es die Alternativen Puppet, Chef, Ansible oder Saltstack gibt.
Auch der Prozess bezüglich der offiziellen Akzeptanz eines "OpenStack-Integrated-Product" war bislang komplex. Das dafür zuständige technische Gremium (Technical Committee) änderte nämlich mit der Entwicklung anderer Kernprodukte laufend seine Anforderungen. In der Folge musste das Projekt Zaqar, früher Marconi (Queuing), dreimal seinen Aufnahmesprozess durchlaufen und dies jedes Mal mit neuen Vorgaben.
Jetzt soll eine Zusammenstellung von dauerhaften Anforderungen es ermöglichen, dass sich Projekte als Teil von OpenStack bezeichnen dürfen.
Das hat einige Vorteile für neue Projekte. Sie bekommen zum Beispiel nun Zugang zu den Mailing-Listen von OpenStack. Vor allem jedoch können sie den "offiziellen" Projekten gemeinsam zur Verfügung stehende Systeme nutzen sowie auf die Teams der Infrastruktur, der Dokumentation und dem Release-Management zugreifen. Um diese nun nicht zu überfordern, müssen die neuen Projekte allerdings einen erheblichen Teil dieser Aufgaben nach vorgegebenen Regeln selbst übernehmen.
Was bedeutet das für die Anwender?
Für die Anwender wird wichtig, dass sämtliche Projekte unter dem OpenStack-Logo Auflagen erfüllen müssen. Die Projekte müssen OpenStack konform zu seinen Regeln und Zielen erweitern. Dies bedeutet: Ihre Entwicklungen und deren Quellcode müssen offen sein. Diese Offenheit und Transparenz wird nicht nur bezüglich der Entwicklung (in den Review & Release Zyklen), sondern auch bezüglich der Projektorganisation (zum Beispiel wählen Mitarbeiter die Projektleiter) und der Architektur verlangt. Abschließend wird die Interoperabilität zu anderen OpenStack-Projekten über APIs gewährleistet.
Künftig sollen Kennzeichnungen ("Tags") den Anwendern kenntlich machen, was sie bei den Entwicklungen der Projekte erwartet: welche Abhängigkeiten zu anderen OpenStack-Produkten (dependencies) es gibt, welche APIs verfügbar sind, was der Release-Stand ist etc.
Das Ganze steht unter Aufsicht des technischen Gremiums von OpenStack, das die Erfüllung aller Kriterien und das "Tagging" überwacht. Damit werden Anwender auch künftig die Sicherheit und Gewissheit haben, auf der Basis von OpenStack und unter einem "Big Tent" offene Cloud-Services zu nutzen oder selbst zu entwickeln. (bw)