La Fondation OpenStack veut mieux structurer les projets communautaires

De la confusion chez les utilisateurs

« Avec l’arrivée de la Big Tent, OpenStack est devenu assez confus. Il est difficile de distinguer ce qui est important et on a le sentiment que les développements ne sont pas ciblés et que la rapidité (d’exécution) fait défaut », montre l’étude de la fondation, citant les propos d’un utilisateur. D’autres appellent la fondation à rester davantage centrée sur les composants cœur (comme Nova ou Neutron), d’autres encore à mettre l’accent sur les standards afin de favoriser la cohérence entre les projets.

« Il y a un projet par semaine à la fondation », illustre un représentant de la société française Osones (spécialiste du monde OpenStack) présente sur l’événement. « Si les projets cœurs sont stables, certains mériteraient que l’on s’y penche davantage comme celui portant sur la database-as-a-service ou le loadbalancing-as-a-service », poursuit-il.

Mais la fondation travaille à résoudre ce problème. Et pour cause, ces projets sont le cœur d’OpenStack et font ce qu’est devenue la plateforme aujourd’hui : un serveur d’intégration et d’API unifiées pour des applications modernes.

L’institution Open Source a d’ailleurs commencé à refactoriser sa liste de projets  dans une nouvelle interface et propose désormais de mieux identifier les thèmes clé via son Project Navigator. Celui-ci liste les 46 composants qui forment l’ossature d’OpenStack et propose des indicateurs concernant le niveau d’adoption,  les déploiements, le niveau de maturité du projet et l’âge du projet.

Toutefois, à l’occasion de l’OpenStack Summit de Boston, nous avons constaté que d’autres projets étaient encore en gestation dans la communauté, à l’image du projet Meteos, dont la vocation est de porter un service de Machine Learning (MLaaS) au dessus d’OpenStack.

Créer les liens avec d’autres communautés

Si Jonathan Bryce confirme que le prise de conscience du problème est apparu l’année dernière, des travaux sont bien en cours pour structurer justement la communauté. « Il est certes difficile d’avoir une vision complète. Mais on peut aussi se poser la même question avec AWS : pourquoi ajoute-t-il autant de services ? Parce que les gens veulent toujours réaliser de nouvelles choses à partir de leur infrastructure », illustre Jonathan Bryce, le directeur exécutif de la fondation. Tout en nuançant : « nous voulons nous assurer que le nombre de projets n’augmente pas de façon systématique et nous réflechissons assidument à ce qu’est un projet, quelles orientations donner et à collaborer étroitement avec les autres communautés ».

La fondation a ainsi des connexions clés avec les communautés derrière les projets Open Source Kubernetes (et donc la Cloud Native Computing Foundation), Ceph et  KVM.

Discipline et intégration

Toutefois, Mark Collier, le COO de la fondation, lui, préfère placer le discours sur le terrain de l’intégration. Selon lui, ce n’est pas tant le nombre de projets qui pose problème que celui de la standardisation et de l’intégration de ces projets. Là est la complexité selon lui. « Avoir plus de projets n’est pas forcément contre-productif, mais il s’agit d’avoir plus de discipline dans la façon dont les composants logiciels sont écrits », soutient-il.

L’un des points forts d’Amazon par exemple est de bien gérer cette intégration entre les différents services. Il s’agirait désormais de reproduire cette expérience utilisateur dans le monde OpenStack, et de l’aligner sur l’approche de plateforme globale innovante que la fondation souhaite donner à OpenStack. Jonathan Bryce confirme que cette intégration des projets et la standardisation sont bien des chantiers en préparation.

Maisi cela ne résoud finalement pas la question du nombre. «Les fournisseurs de solutions OpenStack poussent finalement leurs développements, parce qu’ils sont importants aux yeux de leurs clients. Mais la fondation n’a pour l’heure pas de processus en place qui déterminerait les fonctions manquantes d’OpenStack », résume en substance, Peter Chadwick, en charge de la gestion des produits, du Cloud et de la gestion des systèmes chez Suse, et membre du Product Working Group de la fondation. Il ajoute que chaque projet de la fondation a été approuvé par le Technical Board de la fondation ; d’autres n’ont pas été intégrés à la communauté OpenStack – comme c’est le cas de Crowbar (portail pour automatiser le provisioning de serveurs) illustre-t-il, sans véritablement connaître la raison de ce refus.

Une feuille de route communautaire pour mieux préparer les déploiements

Depuis 2015, la fondation a pourtant mis en place une feuille de route communautaire – publiée tous les trimestres - dont la vocation est d’apporter une vue consolidée sur ce que font les projets , leurs orientations et les améliorations à venir. L’idée est au départ de livrer un programme et un agenda de ces composants afin de permettre aux entreprises qui les ont déployés en production de mieux planifier leurs mises à jour, leurs montées en version ou leur maintenance.

Les membres du groupe de travail Product Working group – dont Peter Chadwick fait donc partie -, ont la charge de cette feuille de route. Ils consolident les données et informations receuillies auprès des contributeurs et des chefs de projets (Project Team Leader). Ces informations livrent par exemple les améliorations prévues pour les trois prochaines versions d’OpenStack.

Les projets sondés en premier sont ceux les plus utilisés dans l’écosystème et ceux listés comme suscitant le plus d’intérêt (ceux dont le taux de déploiement est au moins de 10%) dans l’étude annuelle de la fondation, commente Heidi Joy Tretheway, de la fondation et qui supervise justement cette étude. Dans sa dernière mouture , la feuille de route communautaire fait état des retours de 24 projets, sur 34 ciblés, comme l’indique le document officiel.