Summit OpenStack à Tokyo : jour 3

Publié le 30/10/2015

par Adrien Cunin, Pierre Freund, Jean-François Taltavull, Romain Guichard, Kevin Lefevre

⭠ Retour à la liste des articles

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

Dernier jour pour les conférences et le Marketplace au summit OpenStack de Tokyo. En effet, nombre de visiteurs quittent l'événement ce soir puisque le programme de ce vendredi se concentre sur les "contributors meetups", sessions de travail de plusieurs heures entre développeurs expérimentés.

Task tracking

Cela fait maintenant plusieurs summits que ce sujet est mis sur la table : comment gérer les "tasks" au sein du projet OpenStack.

On parle ici des bugs mais pas uniquement. Historiquement, les bugs d'OpenStack sont suivis sur Launchpad, mais l'outil ne répond plus à l'ensemble des besoins de la communauté. À plusieurs reprises, des alternatives ont été envisagées : logiciels libres existants mais aussi et surtout l'initiative StoryBoard. Storyboard est un projet développé au sein d'OpenStack, pour OpenStack, et par des développeurs OpenStack. Néanmoins la première tentative d'adoption de Storyboard a échoué faute de contributeurs dédiés à son amélioration.

La session d'aujourd'hui visait donc à avancer sur ce sujet, mais nous sommes encore loin d'une solution idéale et évidente.

CloudKitty avec Gnocchi

CloudKitty est un jeune projet, récemment accepté au sein de la "big tent" OpenStack. Cela signifie que le projet poursuit les mêmes objectifs que le reste d'OpenStack et est développé dans les mêmes conditions (principes d'ouverture, choix des technologies et des outils, etc.). Le projet vise à rapprocher un peu plus OpenStack et le monde la facturation. Il se concentre notamment sur l'étape de "rating", qu'il effectue en consommant des métriques. Ces métriques sont issues d'un autre composant, typiquement Ceilometer et maintenant Gnocchi.

Cette session de design a été l'occasion de discuter de l'intégration avec Gnocchi, et plus généralement d'aborder d'autres sujets concernant l'implémentation de la solution.

Glance artifacts

Une session consacrée aux "artifacts" dans Glance. Glance dans OpenStack joue initialement un rôle de catalogue d'images. L'idée est de rendre Glance plus générique en lui permettant de cataloguer d'autres types de ressources. On peut penser à des templates Heat ou encore à des packages Murano.

L'API de manipulation des artifacts en est au stade experimental et a été discutée lors de cette session.

#WeAreOpenStack, mais qui est ce "We" ?

Le statut d'« Active Technical Contributor » (ATC) permet, entre autres, à chaque personne de la communauté OpenStack ayant soumis et fait accepté un patch lors d'un cycle de release donné d'obtenir un pass gratuit pour le summit qui suivant sa contribution. Ce modèle permet de rendre plus accessible cet événement aux contributeurs qui n'ont pas à débourser entre 600 et 1000 dollars pour la semaine de conférence, dont ils sont eux même les acteurs principaux.

Le problème est que la notion de contribution se limite aujourd'hui à la soumission de code. L'activité liée aux groupes d'utilisateurs et les opérateurs d'infrastructure OpenStack ne sont quant à eux pas du tout reconnus comme des contributeurs actifs.

Et pourtant, il faut accepter que le temps où OpenStack n'était qu'un logiciel en développement est révolu. Les organisateurs des summits laissent de peu à peu de la place aux sessions dites « Ops » là ou elles n'existaient pas il y a quelques années. Les retours d'expériences Ops et les échanges Dev <-> Ops sont aujourd'hui acceptés et jugés utiles par la plupart des projets.

La fondation doit maintenant reconnaître que le travail des groupes d'utilisateurs et des opérateurs constitue une contribution. Osones a défendu cette idée pendant deux sessions de cette troisième journée de summit.

La première était la session des embassadeurs de la communauté. Nous avons poussé l'idée que les ambassadeurs devraient avoir la latitude de donner aux groupes d'utilisateurs des accès aux summit en fonction de leur implication dans la communauté (organisation de meetups, participations aux événements libres, etc). Cette idée a été plutôt bien accueillie, et les rares critiques ne tenaient pas vraiment la route. La discussion continue sur la mailing-list communauté.

La seconde était une session consacrée aux retours sur l'organisation de l'OpenStack Summit. Le peu de participants présents nous a permis de nous faire entendre longuement sur les arguments que nous défendons. Les représentants de la fondation ont noté ces remarques et vont les étudier. Reste à trouver un moyen de mesurer objectivement la participation des Ops, alors que ceux-ci peuvent potentiellement ne pas remonter directement les bugs et demandes à la communauté, mais passent peut-être par le support de leur distribution.

Arrêtons de faire des commits ridicules pour obtenir nos pass gratuitement. Notre travail doit être recounnu. #WeAreOpenStack, et non #DevsAreOpenStack.

Où en est le FWaaS ?

Le chantier du Firewall as a Service (FWaaS) a le status "déprécié" dans Mitaka. Ce statut n'est pas synonyme de disparition, mais doit être interprêté comme un signal fort annonçant des changements importants, même si la core team promet un certain niveau de rétro-compatibilité.

Parmi les évolutions prévues nous aurons :

des politiques de sécurité applicables sur les interfaces des routeurs.
la possibilité de combiner les politiques définies via FWaaS avec les règles contenues dans les Security Groups.
l'introduction de la notion de "group" permettant par exemple d'appliquer une politique sur un ensemble d'interfaces en un seul appel à l'API FWaaS.

Par ailleurs, l'équipe projet FWaaS est en train de re-concevoir le service avec entre autres objectifs celui d'introduire un "FWaaS backend" commun aux APIs FWaaS et Security Groups. Côté roadmap, on attend dans Mitaka les "port based policy" et les "groups", l'implémentation de référence du "packet filtering" restant iptables.

Dans la release "N", on devrait disposer d'un firewall iptables scalable et hautement disponible.

Modèle Big Tent et release management : quels changements ?

Session animée par Doug Hellmann et Thierry Carrez.

Avec le modèle Big Tent, la gestion des releases OpenStack évolue du modèle "pre-versioning/time-based" vers le modèle "post-versioning/release as-needed", ce qui était déjà le cas pour Swift, le service Object Storage.

Un nouveau modèle de numérotation a ainsi été inauguré avec le cycle Liberty où l'on a vu apparaître Nova 12.0.0, Keystone 8.0.0, Neutron 7.0.0, Heat 5.0.0 ! Surprenant et surtout déroutant. Mais que l'on se rassure, tout ceci est clairement expliqué sur la documentation. Ces données sont d'ailleurs "machine readable" puisqu'elles sont contenues dans des fichiers yaml.

Par ailleurs, toujours à l'occasion du cycle Liberty, un message encourageant l'utilisation des tags (git) et la rédaction de release notes partielles concernant leur partie a été envoyé aux développeurs, la volonté de la fondation étant clairement d'automatiser tout ce qui peut l'être dans la chaîne de production d'OpenStack.

Encore un petit peu de réseau (mais pas trop)

Nous avons assisté aujourd'hui principalement à des design sessions, dans un premier temps, pour discuter de l'évolution d'Octavia (le nouveau LBaaS de Neutron) ainsi que du FWaaS pour Mitaka.

Pour Octavia, parmi les axes de travail pour la version 2.0 figurent :

Support de l'actif/actif afin de pouvoir scaler facilement.
Choix de la solution pour l'auto-scaling ? Heat ou TaskFlow ?
Implementation de la HA pour le contrôleur Octavia.
Definition des nouvelle API.
Utilisation de conteneurs pour la CI Octavia au lieu de machines virtuelles afin de booster la vitesse des tests.
Redéfinir les test avec tempest et/ou rally.

En ce qui concerne le FWaaS, plusieurs points ont également été abordés, notamment :

Actuellement, le FWaaS est implementé au niveau des routeurs des tenants, l'objectif est de le reporter au niveau des ports Neutron.
Possibilité d'appliquer des règles de pare-feu sur des floating IP.
Fonctionnement avec DVR (Pour plus d'informations sur le sujet ici)

Design sessions Magnum

Chez Osones nous sommes plutôt tendance, on aime les projets Swag. Dans le projet OpenStack la tendance est les conteneurs et leur orchestration. Certains d'entre nous ont passé le reste de la journée aux design sessions de Magnum.

Pour rappel, Magnum est le projet OpenStack qui a pour objectif de fournir un service de conteneurs basé des solutions d'orchestration (appelées COE : Container Orchestration Engine) existantes telles que Kubernetes, Docker Swarm ou Apache Mesos.

La première session était un encouragement à la contribution, Adrian Otto, Project Technical Lead (PTL), a expliqué comment contribuer au projet, les outils utilisés par OpenStack tels que Guerrit pour la revue de code et Launchpad pour les bugs et blueprint. Le guide de contribution est disponible ici.

Quelques points sont à retenir pour bien commencer, même s'ils ne sont pas spécifiques à Magnum :

Être present sur IRC, ne pas hésiter à poser des questions.
Lire / participer aux meetings sur IRC.
Participer à la revue de code et toujours commenter.
Ne pas être découragé par les -1 :).
Discuter avant de commencer de gros changements.

La seconde session concernait la définition du périmètre de Magnum.

Un point important portait sur l'API. Magnum propose actuellement une API qui abstrait certaines fonctionnalités des COE. Cependant, les fonctionnalités offertes par les COE sont très différentes et les concepts ne sont pas forcément les mêmes.

Est-ce que Magnum doit implémenter toutes les API de tous les COE ? Ou bien faut-il supprimer ces fonctionnalités et laisser l'utilisateur utiliser directement les API du COE ? Les avis sont partagés, il y a peut être une solution intermédiaire qui consisterait à implementer uniquement les fonctionnalités communes aux différents COE. Dans tout les cas, ce sera un sujet de discussion important pour Mitaka.

Parmi les autres points de discussion pour Mitaka, on distingue notamment:

L'intégration avec Neutron et Kuryr pour fournir des réseaux communs
L'intégration avec Cinder et Manilla pour fournir des fonctionnalité de stockage

Adrien Cunin Pierre Freund Jean-François Taltavull Romain Guichard Kevin Lefevre

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/ !

Association francophone des utilisateurs d'OpenStack'