Cet article fait partie du dossier spécial OpenStack Summit 2015 :

• OpenStack Summit Tokyo 2015 Jour 1
• OpenStack Summit Tokyo 2015 Jour 1 : Focus sur Neutron
• OpenStack Project Navigator - Comment mesurer la qualité d'un projet OpenStack ?
• OpenStack Summit Tokyo 2015 Jour 2
• OpenStack Summit Tokyo 2015 Jour 2 : Le projet Kuryr
• OpenStack Summit Tokyo 2015 Jour 3

Lors de la première Keynote, de ce summit, Jonathan Bryce a annoncé la création du project navigator, nouvelle rubrique du site openstack.org.
Cette nouvelle section permet d'avoir une meilleur visibilité de l'état d'avancement des différents projets de la "Big tent" OpenStack. Seront indiqués entres autre le niveau de maturité et d'adoption de chaque projet par la communauté.

Mais comment gérer ces nouvelles métriques comme l'adoption ou la maturité ? Si l'adoption peut être mesurée de manière statistique via les enquêtes auprès des utilisateurs, selon quels critères objectifs peut-on mesurer une maturité technique ?
Voici quelques métriques, ajoutées sous forme de tags aux projets, que l'on retrouvera pour chaque projet.

Integration tags

Ces tags doivent permettre de savoir si le projet est intégré avec les autres projets. Est-ce que le projet a un module Heat, Rally, Devstack ou encore OpenStackCLI ? Est-ce que cette intégration avec les autres projets est supportée ? Et si oui par qui ? Pour l'intégration de Designate dans Heat, à proprement parler les ressources Heat pour Designate, les ressources doivent-elles être supportées par l'équipe Heat ou Designate ? Ou les deux ?

La question du packaging a également été évoquée. Doit-on fournir aux utilisateurs une indication sur l'état du packaging ? Cette métrique soulève bon nombre de questions. Qui peut juger la qualité d'un paquet ? Et pour quelles distributions ? Qu'es-ce qu'un bon paquet finalement ?
La discussion a débouché sur une problématique plus générale autour du format des tags, peut-être qu'un format complexe est nécessaire...

Team tags

Ces métriques doivent permettre à l'utilisateur de connaitre la solidité de l'équipe qui maintient le service. De combien de personnes est constituée l'équipe ? Est-ce une seule entreprise derrière le projet (single-vendor) ? Si il n'y a qu'une seule entreprise derrière le projet, avec uniquement quelques "commits" externes, à partir de quel pourcentage de commits externes doit-on considérer le projet comme multi-vendor ?
Enfin, doit-on indiquer un projet multi-vendor à partir de 2, 5 ou même 10 entreprises participantes ? Un projet impliquant 2 entreprises sera-t-il au même niveau qu'un projet avec 10 partiipants ?
Le sujet fait clairement débat.
Cette métrique permettra de détecter les projets supportés uniquement par quelques développeurs, ou par une unique société qui peut arrêter à tout moment son projet, comme cela a été le cas pour MagnetoDB, projet supprimé, mettant en situation difficile ses utilisateurs.

Contract tags / QA release

Il a également été évoqué des métriques liées à l'état du projet, comme le fait d'être déprécié, autorisant les rolling updates ou la version de l'API.
Le projet subit-il des tests complets ou partiels ? Dans le cadre d'un projet complexe comme Neutron, doit-on tester tous les modules ? Qu'en est-il de la scalabilité ? Comment juger qu'un service est scalable avec la complexité et le nombre de plugins d'un service comme Neutron ?
Enfin, des métriques liées à la sécurité ou à la validation des releases ont été abordés. Ces sujets étant potentiellement utiles pour des utilisateurs spécifiques comme les packagers.

Conclusion

L'annonce faite lors de la keynote a surpris certains contributeurs OpenStack, qui ont vu un projet controversé sortir en production par surprise. Le ton est monté pendant les sessions designops, notamment au sujet du packaging qui pose de très nombreuses problématiques derrière un simple tag "packaging".

Pierre Freund

Rejoignez vous aussi la conversation !

Questions, remarques, suggestions... Contactez-nous directement sur Twitter sur @osones !
Pour discuter avec nous de vos projets, nous restons disponibles directement via contact@osones.com !
Enfin, la communauté Francophone d'OpenStack vous attend sur http://openstack.fr/ !