PTG (Project Team Gathering) est un événement où les équipes de développement se rencontrent pour discuter des tâches, des statuts et des plans actuels. Il y a plusieurs années, PTG s'est séparé du sommet OpenStack traditionnel.
PTG a d'abord eu lieu en ligne via Zoom et Jitsi Meet. Cependant, la combinaison de l'image et du son lors de la réunion a rendu ce changement complètement imperceptible, en particulier dans le contexte des réunions d'équipe IRC désormais familières.
Les sessions Neutron de trois heures se sont déroulées du mardi au vendredi. Les principaux procès-verbaux de la réunion sont publiés sur OpenStack Etherpad et sur la liste de diffusion OpenStack. L'ordre du jour de l'événement a été établi sur la base des propositions des développeurs de neutrons, et le calendrier de la réunion a été préparé par son président, PTL (chef d'équipe du projet) de l'équipe Neutron Slawek Kaplonski.
Dans cet article, je parlerai de 3 sujets qui, à mon avis, méritent une attention particulière et nécessitent une petite explication.
OVN
On a beaucoup parlé d'OVN sur ce PTG, ce qui n'est pas surprenant puisque la plupart des membres de l'équipe principale représentent RedHat, le principal contributeur à OVN.
Qu'est-ce que l'OVN?
- Virtualisation de réseau Open source L2 / L3 pour Open vSwitch (OVS):
- Commutateurs logiques
- Routeurs logiques IPv4 et IPv6
- ACL L2 / L3 / L4 (groupes de sécurité)
- Superpositions de tunnels multiples (Geneve, STT et VXLAN)
- Équilibreurs de charge logiques
- Passerelles L2 logico-physiques basées sur TOR
- Passerelles logico-physiques L2 / L3 logicielles
- Fonctionne sur les mêmes plates-formes que OVS:
- Linux
- Conteneurs
- DPDK
- Intégration avec:
- OpenStack Neutron
- Essaim de dockers
- Kubernetes
Architecture OVN
«OVN en 75 mots.
L'Open Virtual Network est géré par le projet OVS et développé par l'équipe OVS d'origine. Cette décision est une tentative de refonte du plan de contrôle ML2 / OVS sur la base d'années d'expérience. Il est destiné à être utilisé avec OpenStack et Kubernetes. OVN repose sur une nouvelle architecture qui a abandonné le concept d'agents Python interagissant avec le service de l'API Neutron via RabbitMQ au profit des démons C communiquant via OpenFlow et OVSDB. » - Slawek Kaplonsky, Neutron PTL.
Initialement, le pilote Neutron OVN a été développé en tant que projet distinct dans le stade Neutron - réseau-ovn, et dans la version Ussuri a été inclus dans le référentiel Neutron principal.
Ainsi, cette solution élimine le problème principal de ML2 / OVS - RabbitMQ, qui est un plus incontestable, et en général «l'objectif de conception d'OVN est d'avoir une mise en œuvre de qualité production qui puisse fonctionner à une échelle significative». Cependant, OVN prend-il en charge les fonctionnalités disponibles lors de l'utilisation de ML2 / OVS? Il semble que ce ne soit pas tout à fait vrai, ce qui est devenu l'un des sujets de discussion sur PTG. En conséquence, plusieurs lacunes ont été mises en évidence (une liste complète est disponible sur la page du projet). Tout d'abord, les développeurs ont noté l'absence ou une prise en charge incomplète des réseaux routés, de certaines fonctionnalités de QoS, du BGP et des zones de disponibilité. Bien que l'équipe de l'OVN soit prête à faire tout ce qui précède, au cours de la réunion, elle a admis que cela n'avait pas été une priorité pour elle auparavant - car les intérêts internes étaient plus importants. De plus, le développement de ML2 / OVS, bien sûr,ne s'arrête pas, ce qui signifie que de nouveaux espaces peuvent apparaître.
Cependant, à mon avis, le principal problème avec OVN est qu'il n'est pas encore largement utilisé et n'a pas été testé sur de grandes installations. De plus, il y a quelques questions sur la haute disponibilité:
- L'un des principaux composants, ovn-northd, ne prend actuellement en charge que le mode HA actif / passif, l'actif / actif n'est prévu que pour le moment
- Un autre composant central, ovsdb-server, ne prend également en charge que le mode actif / passif
Il est possible que le dernier point soit réellement obsolète, car le support du cluster ovsdb (basé sur l'algorithme Raft) a été ajouté depuis OVS 2.9, mais il n'est pas clair si cela a été testé dans la version avec OVN et OpenStack. Par exemple, le ticket associé dans openstack-ansible n'a pas encore été fermé.
Il est également préoccupant qu'OVN utilise des tunnels Geneve au lieu de VxLAN, ce qui affecte les paramètres MTU (les en-têtes Geneve sont plus grands que les VxLAN) et prend en charge le traitement de tunnel accéléré par le matériel.
Quoi qu'il en soit, le projet prend rapidement de l'ampleur et il semble que dans quelques versions, OVN devrait devenir un plugin Neutron de base. De plus, lors du PTG, les développeurs de l'équipe principale ont accepté de faire d'OVN le plugin par défaut pour DevStack.
Où ces changements mèneront:
- OpenStack Neutron CI,
- ML2/OVS ( )
- Neutron CI , ML2/Linuxbridge ML2/OVS – ,
- , core OVN
Concernant le dernier point, Neutron PTL a publié le message suivant: «L'équipe Neutron estime que l'OVN et le pilote Neutron OVN sont construits sur une architecture moderne qui fournit une meilleure base pour une solution plus simple et plus efficace. Nous constatons un engagement accru dans kubernetes-ovn, conduisant à une expansion de la communauté OVN principale, et nous aimerions qu'OpenStack profite également de cet investissement dans OVN de Kubernetes.
Pour le moment, le pilote Neutron OVN présente des lacunes dans la fonctionnalité prise en charge par rapport à ML2 / OVS, cependant, notre équipe tente de combler ces lacunes, et nous pensons que ce pilote sera l'avenir de Neutron, et par conséquent, nous voulons en faire le backend Neutron ML2 par défaut pour DevStack. "
Jusqu'à présent, la réaction à cette nouvelle est plutôt positive, bien qu'il y ait encore des doutes sur la transition du VxLAN vers les tunnels de Geneve, comment migrer de ML2 OVS vers ML2 OVN, ainsi que sur les performances et les fonctionnalités prises en charge.
Application du nouveau EngineFacade
EngineFacade est un framework au-dessus de sqlalchemy qui intègre la logique de base de données utilisée dans tous les projets OpenStack. Il y a plusieurs versions, il a subi une refactorisation, ce qui a conduit à l'apparition du soi-disant «nouveau EngineFacade». L'étape suivante consistait à adapter ce framework à OpenStack.
À mon avis, ce sujet a été inclus dans l'ordre du jour du PTG en raison du fait que le travail sur ce sujet traîne depuis plusieurs versions et n'est pas encore terminé. Les raisons de cette évolution des événements sont un grand nombre de changements nécessaires, des problèmes non triviaux dans le processus d'adaptation et, il me semble, un manque de motivation, et donc de ressources humaines. En effet, pourquoi changer quelque chose qui fonctionne déjà et qui ne donne même pas un tas de bugs? Une réponse assez détaillée à cette question est présentée dans la spécification de Mike Bayer. Ici, je vais essayer de donner un bref résumé des considérations à l'appui d'EngineFacade afin que vous n'ayez pas à lire ce long texte:
- L'ancien EngineFacade fournit des API de bas niveau au lieu d'API de haut niveau adaptées à un cas d'utilisation spécifique, il s'agit donc essentiellement d'une usine, pas d'une façade. Par conséquent:
- EngineFacade OpenStack
- , ,
- EngineFacade // : reader writer, , .
Cela semble simple et logique, alors quel est le problème avec l'adaptation EngineFacade alors? Pour être honnête, je ne suis pas allé beaucoup dans les détails, mais il semble que la cause principale des problèmes est que dans certains scénarios complexes, l'ancien EngineFacade a été mal utilisé dans Neutron et cela a fonctionné (!), Et le nouveau EngineFacade essaie de tout faire correctement, mais néanmoins, cela casse les scripts de travail (à mon avis, un problème assez typique lorsqu'on travaille avec du code hérité). Evidemment, dans ce cas, vous devez d'abord corriger la logique de ces scripts.
En fait, il ne reste plus grand-chose à modifier - juste un patch, et l'équipe principale a accepté de résoudre conjointement ce problème. Bien sûr, toute personne intéressée peut aider à l'analyse et à la révision!
Neutron-lib
Plusieurs sujets ont été consacrés à neutron-lib. Pour commencer, permettez-moi de vous rappeler ce que c'est pour ceux qui ne sont pas fortement impliqués dans le développement de Neutron. Premièrement, Neutron n'est pas un projet unique - en fait, il se compose de plusieurs référentiels travaillant avec différentes zones du réseau OpenStack sous le nom général de Neutron Stadium, et «neutron» n'en est qu'un, même s'il s'agit d'un projet majeur. Le reste des projets concerne les services dits avancés (par exemple, neutron-lbaas, -fwaas, -vpnaas, -dynamic-routing, etc.) et les plugins tiers / fournisseurs (par exemple, networking-midonet, -odl, -ovn). Cette liste comprend les projets développés par Neutron PTL et l'équipe de base et qui y sont directement impliqués au quotidien. Pour ce faire, ils veillent à ce que les principes généraux et les règles de travail soient respectés dans tout le stade dans tous les aspects du développement - structure,développement, style de code, tests, documentation, etc. Pour être honnête, ce n'est pas tout à fait vrai aujourd'hui et le principal fardeau incombe toujours aux responsables du projet.
Avant la création de neutron-lib, tous les projets de mise en réseau importaient tout le code commun - constantes, interfaces (classes de base abstraites), fonctions d'assistance, et plus encore - du référentiel principal de neutron. Toute modification de ce code dans neutron pourrait interrompre les projets dépendants. Ensuite, dans la version Ocata, l'initiative neutron-lib a été lancée pour résoudre ce problème: tout le code commun doit maintenant être stocké dans un référentiel séparé et doit être versionné. Plus précisément, les objectifs ont été formulés comme suit:
- Supprimer la dépendance des sous-projets de Neutron (c'est-à-dire supprimer les importations directes de neutrons dans les sous-projets)
- Faites vos devoirs dans Neutron en refactorisant le code ou en redessinant l'architecture de motif sous-optimale dans les sections neutron-lib appropriées
En fait, neutron-lib ressemble à une option gagnant-gagnant: à la fois le Neutron principal et les services de projets tiers devraient être dans le noir en conséquence. Qu'est ce qui ne s'est pas bien passé?
Manque de soutien
Aucun projet open source ne peut exister sans le soutien de contributeurs et de mainteneurs, des personnes prêtes à investir leur temps dans le travail sur un projet. Pour neutron-lib, il y avait un manque de tels volontaires, et en conséquence, la logique originale a cessé de fonctionner, c.-à-d. de sorte que tout le code commun serait stocké ici qui pourrait être importé au lieu d'importer des neutrons. Le principal responsable neutron-lib (boden) a quitté le projet il y a quelque temps. Pendant le PTG, une proposition a été faite d'abandonner l'idée de porter tout le code commun vers neutron-lib, ou même de porter le code neutron-lib vers neutron. Cette proposition n'a pas été adoptée pour deux raisons:
- neutron-lib est encore largement utilisé
- neutron-lib a une certaine valeur dans la mesure où il met en évidence les interfaces standard qui ne peuvent pas être modifiées afin de ne pas interrompre plusieurs projets à la fois
Suite à la discussion, neutron-lib reste inchangé, mais la politique de relocalisation et de dépréciation du code neutron doit être mise à jour.
Bien sûr, tout nouveau code devrait être partagé entre neutron et neutron-lib, si possible. Et cela nous amène au deuxième problème.
Problème de test
Un autre problème concerne les tests pendant le développement. Si une partie d'un patch dans neutron introduit un nouveau code partagé ou modifie le code partagé existant, il doit être envoyé à neutron-lib par des règles. Cela rend la partie neutronique du patch dépendante de ces changements de lib. Cependant, les correctifs neutrons sont actuellement testés sur la version de sortie de neutron-lib pour vérifier qu'ils fonctionnent avec la dernière version. En conséquence, ces correctifs ne réussiront pas les tests en CI.
Tester tous les correctifs neutrons avec le code neutron-lib de l'assistant présente également quelques inconvénients. Par exemple, il n'y a aucune garantie que l'assistant neutron fonctionnera avec la dernière version de neutron-lib, que les utilisateurs finaux utilisent.
Voici les moyens de résoudre ce problème (merci à Bence Romsics pour l'excellent résumé):
- , , neutron-lib , neutron .
- , :
- , “foo” neutron-lib, . neutron , “_foo” TODO , , neutron-lib.
- neutron-lib , neutron, _foo “import _foo” “from neutron-lib import foo”.
- De plus, vous pouvez exécuter des vérifications séparées sur CI avec à la fois l'assistant et la dernière version de neutron-lib. Mais un seul d'entre eux peut voter. Le simple fait de doubler le nombre de tâches ajoutera une énorme charge supplémentaire à l'infrastructure OpenStack CI.
Au cours de la discussion à PTG, trois propositions ont été faites:
- Utilisez l'assistant neutron-lib pour «Check CI»; utilisez la version de libération de neutron-lib pour «Gate CI» - cependant, si le patch neutron passe les contrôles «Check CI» et plante sur «Gate CI», cela aura l'air étrange
- Ne changez rien: il est préférable d'exécuter des tests sur la version de neutron-lib. Par exemple, cela est maintenant fait pour OSC (OpenStackClient)
- Exécutez des tests avec l'assistant neutron-lib et ajoutez une tâche périodique pour les tests avec la version neutron-lib
Solution finale: créer un nouveau problème sans vote dans «Check CI» avec neutron-lib de la branche master. Fondamentalement, tout reste tel quel, mais il sera possible de vérifier qu'une fonctionnalité qui inclut des changements de neutrons et de neutrons-lib passe par CI avant de la confier à la branche maître.
J'espère que cet article vous a été utile et vous a aidé à mieux comprendre où et pourquoi Neutron se dirige.
Merci de votre attention!