OpenStack: Die Herausforderung nahe am Upstream-Code zu bleiben und neuen Code an die Community weiterzuleiten

""Zusammenfassung

• Die Integration von OpenStack
• OpenStack musste für die Public Cloud angepasst werden
• Nach zwei Jahren mit OpenStack
• Ein Problem oder doch große Chance?
• Für die Verwaltung einer Infrastruktur der Größe der auf OpenStack Technologie aufgebauten OVH Public Cloud sind nicht nur konstante Instandhaltungsarbeiten nötig.
  
  Auch die Bedürfnisse und Erwartungen der Kunden müssen dabei erfüllt werden. Hinzu kommt, dass OpenStack immer neue Versionen veröffentlicht und Kunden immer mehr Features erwarten. Dies stellt Cloud-Anbieter vor eine enorme Herausforderung.
  
  Die Integration von OpenStack OVH hat diese Herausforderung angenommen und seit 2012 zahlreiche OpenStack-Projekte erfolgreich abgeschlossen. Begonnen hat diese Zusammenarbeit, als wir für HubiC nach einer skalierbaren Storage-Lösung suchten und diese in Form von OpenStack Swift fanden. Seitdem haben wir die auf OpenStack basierende Infrastruktur stark ausgebaut und wurden 2015 als Infrastructure Donor ausgezeichnet. Schließlich erhielt OVH 2016 auch die OpenStack Powered Zertifizierung für die gelungene Integration der OpenStack Technologie.
  
  OpenStack musste für die Public Cloud angepasst werden OpenStack ist ursprünglich nicht für die Public Cloud konzipiert. Daher müssen Public Cloud-Anbieter zuerst einige für OpenStack typische Schwierigkeiten überwinden. So war OpenStack vor zwei Jahren noch nicht dazu in der Lage, den grundlegenden Nord-Süd-Traffic angemessen zu verwalten. Um dieses Problem zu lösen, haben wir damit begonnen, OpenStack zu patchen und haben den ursprünglichen Network-Node von diesem Pfad entfernt sowie Neutron anschließend mit einem umfangreichen Patch angepasst. Für unsere Beta-Version wurde diese Änderung bei OpenStack Juno vorgenommen. Die Public Cloud wurde daraufhin weiter entwickelt und wir haben immer mehr kleine und auch größere Patches zu unserem Produktzweig hinzugefügt. Diese dienten sowohl dazu, unsere eigenen Anforderungen zu erfüllen als auch speziellen Kundenwünschen nachzukommen.
  Nach zwei Jahren mit OpenStack Blicken wir zurück, was zwei Jahre nach den ersten Anpassungen von OpenStack geschehen ist. Welche Auswirkungen hatten die speziellen Wünsche unserer Kunden, der umfangreiche Bedarf an Änderungen und die Verwendung interner Tools? Wir haben damals beschlossen, uns etwas weiter vom OpenStack Code zu entfernen, um unseren Kunden eine für sie optimierte Version anzubieten. Allerdings war diese schließlich soweit vom Upstream-Code entfernt, dass der neue Code nicht einfach von der OpenStack Community übernommen werden konnte. Die Unterschiede lagen dabei nicht bei Features und API-Kompatibilität, sondern betrafen den Code selbst. Mit jedem neuen Patch wurden die Unterschiede zum Upstream-Code größer und der gegenseitige Austausch von Patches und neuen Versionen schwieriger. Es gibt mehrere Gründe für diese Vorgehensweise: So bleiben manchmal bleiben  nur wenige Stunden für eine Neuerung. Wenn wir jedoch einen Patch aus Zeitgründen zu schnell an die Community weiterleiten, kann er meistens nicht mehr zeitnah von ihr integriert werden. So entwickelten wir einen Patch für Swift, um Anfragen zu kontrolliere. Entwicklung, Test und Prodding nahmen dabei volle drei Tage in Anspruch. Anschließend gaben wir den Patch an die Community weiter. Dort war der Validierungsprozess dann allerdings nach drei Monaten noch nicht abgeschlossen.
  
  Herausforderung oder große Chance? Wir werten diese Situation als eine großartige Chance. Während sich die Community auf ein globales System für eine ausgeklügelte, aber doch eher allgemeine Cloud-Lösung konzentriert, arbeiten wir hier bei OVH an Lösungen, die optimal an die Public Cloud angepasst sind. Eine ideale Ausgangssituation, um zusammenzuarbeiten. Schließlich liegt doch darin die Stärke der Open Source Community: verschiedene Ansätze voll auszunutzen und zusammen auf ein gemeinsames Ziel hinzuarbeiten. Auf unserer Seite haben wir uns dafür entschieden, systematisch an unserem eigenen OVH Master Branch zu arbeiten, den wir möglichst nahe am Upstream-Code halten und täglich aktualisieren. Alle unsere Patches werden auf dieser Grundlage entwickelt. Daher können wir jederzeit und problemlos unsere neuen Patches an die Community weitergeben. Das eigentliche Ziel ist dabei nicht, dass unser Patch direkt angenommen wird. Viel wichtiger ist es uns, einen Use Case und eine erste mögliche Lösung aufzuzeigen. Die Entwickler der Community können dann entscheiden, ob der Patch zu spezifisch ist, ob sie ihn verändern (z. B. wenn er nicht zur aktuellen Richtung des Projekts passt), oder ob sie ihn einfach übernehmen. Um den Patch im entsprechenden Produktionszweig zu verwenden, müssen wir den Code einfach nur von unserem Master Branch importieren. Für uns ein wirklicher Vorteil, da wir nun unseren Master Branch jederzeit nutzen können. Unsere Änderungen wurden bereits vollständig integriert. Idealerweise sollte dieser Workflow auf alle Open-Source-Projekte angewandt werden, die auf einer Produktionsumgebung basieren und bei denen Code-Änderungen vorgenommen werden.""