OVH NEWS | ACTUALITÉ, INNOVATION ET TENDANCES IT


Découvrir, comprendre et anticiper









Le 10 / 05 / 2017
Partagez

Dossier rédigé par Hugo Bonnaffé & Adam Kijak


OpenStack : de la difficulté de rester proche du code upstream en production et de reverser du code à la communauté


Gérer une infrastructure à grande échelle, comme le Public Cloud OpenStack d'OVH, nécessite d'assurer une maintenance constante tout en répondant aux besoins et aux attentes des clients. Qui plus est, OpenStack sort en permanence de nouvelles versions et les clients demandent toujours plus de fonctionnalités. Il s'agit là d'un challenge considérable qui demande une gestion intelligente de la part du fournisseur. Voici, dans les grandes lignes, le contenu de la conférence donnée aujourd’hui à l’OpenStack Summit de Boston par Adam Kijak, DevOps chez OVH.



Patcher OpenStack : l’adapter au cas d’usage du cloud public


A l'origine OpenStack n'a pas été conçu pour le cloud public, environnement dans lequel les fournisseurs doivent faire face à un certain nombre d'enjeux spécifiques à cette plateforme. A titre d'exemple, le trafic réseau Nord-Sud est dense et hautement critique, et il y a deux ans les solutions proposées par OpenStack n’étaient pas satisfaisantes. Pour améliorer cela, nous avons entrepris de « hacker » OpenStack afin de supprimer le nœud réseau de ce chemin d'accès et avons ajouté un patch important sur Neutron. Cela s'est fait, pour notre version bêta, sur Juno. Par la suite, nous avons mis en production notre offre Public Cloud et avons continué à ajouter toujours plus de patchs à notre branche de production, plus ou moins importants, visant à répondre à la fois à nos propres besoins ainsi qu’aux demandes spécifiques des clients.






De la difficulté de rester upstream en production


A présent, prenons du recul et observons ce qui s'est passé à la suite de deux années à satisfaire des demandes de fonctionnalités par les clients et des besoins internes liés à la gestion d’infrastructures à grande échelle. Nous constatons que nous sommes en train de « forker » OpenStack dans le but de fournir une version parfaitement adaptée à nos clients. Les fonctionnalités et la compatibilité API restent les mêmes, mais le code diverge de plus en plus du code d’origine. A chaque création de patch nous nous éloignons des dépôts source du projet.






Par conséquent, nous n'avons pas pu intégrer certaines fonctionnalités récentes dans notre propre branche de production, ni par ailleurs soumettre nos changements à la communauté. En outre, la même fonctionnalité est parfois développée en doublon, une fois chez OVH et une autre au sein de la communauté, mais via un code différent.

Ce modèle signifie que la contribution à la source est un processus difficile et long.



Chez OVH, nous sommes plus Ops que Dev


De nombreuses raisons, incluant les contraintes de temps, expliquent notre choix de modèle. Parfois nous ne disposons que de quelques heures pour répondre à un besoin spécifique. Lorsque le patch créé dans ce cadre est remonté à la communauté, la plupart du temps il n'est pas validé. A titre d'exemple, nous avons développé un patch sur Swift pour gérer les requêtes entrantes. Il nous aura fallu trois jours pour développer, tester et mettre le patch en production. Nous l'avons soumis à la communauté et trois mois plus tard le patch était toujours en discussion. Cependant, nous avons bien utilisé le patch pendant ces trois mois car nos clients en avaient besoin !

Comment en arrive-t-on alors à ce genre de situation ? La réponse est plutôt simple. La majorité des techniciens de la communauté OpenStack travaille comme des DevOps. Toutefois, chez OVH nous sommes plus Ops que Dev, c’est-à-dire que nous priorisons les contraintes opérationnelles, alors que pour la communauté OpenStack est plus Dev que Ops et priorise quant à elle les contraintes de design global et d’architecture.






Et si cette difficulté était finalement une opportunité d’améliorer notre workflow ?


Alors que la communauté se focalise sur le système général nécessaire à une solution cloud bien conçue, notre priorité est la création de solutions « qui fonctionnent ». Cela nous offre une opportunité unique de travailler ensemble. Et après tout, ne serait-ce donc pas la force de la communauté open source ? Tirer profit des différentes approches et travailler dans un but commun ?

Du côté d'OVH, nous avons opté pour travailler systématiquement sur notre propre master branch OVH, en la gardant aussi proche que possible de la master branch source et en la mettant à jour quotidiennement. C'est le point de démarrage du développement de tous nos patchs. Suivre cette ligne directrice signifie que nous sommes toujours prêts à ajouter facilement des patchs au référentiel communautaire. L'approbation du patch ne constitue pas réellement l'objectif principal. Le but étant de présenter un use case et de fournir une solution envisageable. La communauté est donc libre de l'abandonner si elle le trouve trop spécifique, d'y travailler plus en profondeur lorsque notre implémentation ne suit pas la direction actuelle du projet ou de simplement l'accepter.

Afin de se servir du patch sur notre branche de production, nous devons simplement l'importer depuis notre master branch dans notre base de code de production. C'est pour nous un avantage nouveau et réel puisqu'il signifie que nous pouvons utiliser notre master branch actuelle à notre guise. Tous nos changements ont déjà été intégrés.






Idéalement, ce workflow devrait être utilisé le plus possible pour des projets open source basés sur un environnement de production et l'implémentation des modifications de code.