Dette technique et sécurité au menu d'Openstack Flamingo

15 ans après sa création, Openstack opère un grand chantier pour combler sa dette technique. A l’occasion de sa version Flamingo, le framework open source en gestion d’infrastructure cloud supprime en effet les dépendances Eventlet dans l’ensemble de ses composants. Eventlet est une bibliothèque de concurrence (concurrent library) permettant l’exécution simultanée de plusieurs tâches ou processus en utilisant des ressources identiques ou différentes. Elle a été créée il y a près de 18 ans, à une époque où les fonctionnalités asynchrones étaient absentes de la bibliothèque standard CPython. Avec le temps, celui-ci a évolué, tout comme CPython, mais depuis plusieurs années, l'activité de maintenance d'Eventlet a diminué, ce qui a entraîné un écart croissant entre Eventlet et l'implémentation CPython. « OpenStack s'est lancé dans une initiative technique majeure visant à supprimer les dépendances Eventlet dans tous ses composants », explique le fournisseur.

Les composants phares d’Openstack émancipés d’Eventlet

À sa création, OpenStack a été développé avec le langage de programmation open source Python 2, remplacée depuis par Python 3, disposant de son propre framework de concurrence, mais de nombreux projets OpenStack ont continué à s'appuyer sur Eventlet. « Notre dépendance était vraiment un casse-tête. Elle menaçait la viabilité à long terme du projet, car de moins en moins de personnes travaillaient sur Eventlet en Python », explique Thierry Carrez, general manager de l’OpenInfra Fondation qui vient par ailleurs de rejoindre la fondation Linux. La migration fait l'objet de discussions depuis des années. Elle a pris un élan significatif au cours de ce cycle, lorsque la communauté a formé des équipes dédiées. Les avantages vont au-delà de la simple utilisation d'un code pris en charge. « Elle présente tous les avantages liés à l'adoption d'un framework moderne développé nativement pour le langage, par opposition à l'utilisation d'un élément développé comme extension pour une version précédente de Python », explique M. Carrez. Avec à la clé des bénéfices variés en termes de maintenance, de performance et de compatibilité.

A ce jour plusieurs composants OpenStack utilisent désormais le framework asyncio natif de Python 3 : le service d'orchestration Heat (depuis juillet 2025), Ionic (bare metal) et Barbican (gestion des clés) depuis août, et Mistral (workflow as a service) en septembre. D’autres projets sont en cours de migration : Nova (compute), Neutron (networking), Cinder (stockage bloc), Swift (stockage cloud distribué), Glance (découverte et enregistrement d’images de VM et de containers), Manila (système de fichiers partagés), Watcher (optimisation des ressources), Designate (DNS a s a service) et les bibliothèques Oslo. Pour le service de réservation de ressource Blazar la migration est à l’étude.

Des améliorations en sécurité et confidential computing

Les évolutions en matière de sécurité constituent un autre pan de cette 32e version d'OpenStack. Le projet Nova compute ajoute par exemple le support de l’attachement des périphériques à usage unique. Ces derniers sont alloués une seule fois à une nouvelle instance. Lors de la suppression de cette instance, les périphériques ne seront pas automatiquement réaffecté (comme c'est généralement le cas) et resteront réservés. Les opérateurs peuvent ainsi effectuer des contrôles de sécurité ou des réinitialisations matérielles avant de réutiliser les périphériques. Nova ajoute également support de Secure Encrypted Virtualization with Encrypted State (SEV-ES) d’AMD pour répondre aux besoins de confidential computing. Cette fonction protège à la fois la mémoire invitée et les registres du CPU. Toujours sur la mémoire, le pilote libvirt supporte la fonction de délestage mémoire automatisé pour l’hyperviseur open source de type 2 QEMU. Avec cette capacité, Nova réduit le risque d’activation du mécanisme ou-of-memory killer. « Cela permet de récupérer beaucoup plus rapidement de la mémoire et d’utiliser de la mémoire partagée dont on a besoin sur une instance », poursuit M. Carrez.

Au-delà de Nova, d'autres projets OpenStack bénéficient également d'améliorations progressives en matière de sécurité. Le projet Magnum (container as a service) offre désormais la rotation des identifiants du cluster Kubernetes et le transfert de propriété. Les services de systèmes de fichiers partagés Manila intègrent désormais le chiffrement BYOK (bring-your-own-key) pour les serveurs partagés. Enfin, le tableau de bord Horizon introduit l'affichage de codes QR pour la configuration de l'authentification TOTP (mot de passe à usage unique et à durée limitée) pour simplifier la configuration de l'authentification multifacteurs.

Neutron fait progresser l'intégration OVN

Le service de réseau Neutron introduit plusieurs bénéfices axés sur les déploiements open virtual network (OVN) et le contrôle d'accès dans la version Flamingo. OVN est une solution de virtualisation réseau qui fournit des capacités de SDN pour OpenStack. Elle utilise Open vSwitch pour mettre en œuvre des réseaux virtuels et des services de couches 2/3. L'agent OVN a remplacé OVN Metadata qui sera abandonné dans une prochaine version. Pour les opérateurs utilisant OVN, cela représente une consolidation des fonctionnalités. Cela simplifie l'architecture de l'agent sur les nœuds de calcul. Les règles NAT IP flottantes dans OVN peuvent désormais être configurées en mode stateless. L'option stateless_nat_enabled améliore potentiellement les performances en évitant la surcharge liée au suivi des connexions. Cela est particulièrement avantageux pour les scénarios à haut débit où le suivi de l'état des connexions ajoute de la latence. Le NAT stateless réduit la surcharge associée à la maintenance des tables d'état des connexions.

Neutron ajoute par ailleurs une autre règle API personnalisée appelée context_with_global_access pour spécifier des rôles tels que celui d'auditeur pour un meilleur contrôle des accès. Les entreprises peuvent désormais accorder un accès en lecture seule à des fins d'audit sans droits administratifs complets. Le contrôle granulaire des politiques aide à mettre en œuvre une séparation appropriée des tâches. Cette version comprend également des améliorations incrémentales des règles NAT et des règles de politique à travers la pile réseau.

En route vers l'inférence IA

OpenStack a un cycle de publication de six mois entre chaque version. La prochaine version, nommée Gazpacho est prévue pour avril 2026. À l'avenir, M. Carrez s'attend à ce que la communauté achève la migration Eventlet dans tous les projets. Cela devrait se produire au cours du prochain cycle de publication. Les charges de travail d'inférence IA apparaissent également comme un domaine prioritaire. « Comme nous constatons que l'inférence est un type de charge de travail de plus en plus important, je pense que nous verrons apparaître des fonctionnalités et adaptations au niveau d'OpenStack », a déclaré M. Carrez. « Si nous avons de plus en plus de charges de travail d'inférence et de moins en moins de charges de travail d'entraînement, cela signifie que la manière dont les GPU sont partagés entre les différentes charges de travail sur la machine va évoluer et nécessiter un support au niveau d'OpenStack. »

Selon la fondation, OpenStack fonctionne aujourd'hui sur plus de 55 millions de cœurs de calcul dans des systèmes de production à travers le monde. Près de 480 contributeurs issus de plusieurs entreprises, dont Ericsson, Rackspace (co-créateur d’OpenStack avec la Nasa), Red Hat, Walmart, Samsung SDS, SAP et Nvidia, ont collaboré pendant six mois pour créer Flamingo, qui introduit près de 8 000 modifications.