Intro

Une partie de l'équipe Alter Way Cloud Consulting a rejoint les États-Unis ce week-end, et plus précisément le Colorado, afin de participer au premier Open Infrastructure Summit qui se déroule à Denver pendant trois jours à partir de ce lundi. Open Infrastructure Summit est le nouveau nom de l'OpenStack Summit, il s'agit pour la Fondation OpenStack d'accompagner son évolution vers un domaine un peu plus élargi que simplement OpenStack.

View this post on Instagram

#OpenStackSummit #openinfrasummit #OpenStack #denver #awcc #teamspirit #colorado #osones

A post shared by AWCC (@livinthecloud) on Apr 29, 2019 at 1:44pm PDT

Les keynotes du début de journée furent l'occasion de rappeler quelques chiffres à propos d'OpenStack : 105 000 membres issus de 180 pays au sein de la communauté et un marché représentant 6,1 milliards de dollars.

Kata Containers et Zuul, deux des quatres nouveaux projets hébergés par la Fondation OpenStack, ont été l'objet de présentations spécifiques : Kata Containers et son support de Firecracker, Zuul et sa fonctionnalité de speculative execution. Ces deux projets sont d'ailleurs officiellement confirmés, ils ne sont plus des pilot projects, Zuul ayant été confirmé ce dimanche lors de la réunion du Board de la Fondation.

Ironic a aussi été sous le feu des projecteurs. Même si Ironic est un module faisant partie d'OpenStack (il n'est donc pas à placer sur le même plan que Kata Containers et Zuul), puisqu'il est utilisable et utilisé en mode standalone pour nombre de cas d'usage, la Fondation communique sur le sujet. Une démonstration en direct de l'utilisation d'Ironic au travers de Kubernetes fut d'ailleurs une réussite.

Sessions

Open Source is not enough

Thierry Carrez, VP Engineering de la Fondation OpenStack, consacre cette présentation à l'idée que l'aspect "open source" des projets libres n'est pas suffisant en tant que tel. Pour garantir aux utilisateurs l'ensemble des avantages du logiciel libre, il est important de s'intéresser notamment à la façon dont le logiciel est construit, par qui, avec quels outils, etc.

On note qu'en réalité, les logiciels libres produits par des communautés réellement ouvertes sont rares. Les autres logiciels, juste "open source", peuvent l'être pour plusieurs raisons, par exemple lorsqu'une seule entreprise travaille dessus (single vendor) ou lorsque le modèle open core est utilisé.

Il faut donc faire attention à la diversité des contributeurs, au choix des outils (Free Software need free tools), à permettre à tout le monde de travailler d'égal à égal ; la licence ne suffit pas.

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23361/open-source-is-not-enough

Swift project update

John Dickinson présente son dernier project update de Swift, en effet il laisse sa place en tant que PTL à partir de maintenant. Ce fut donc l'occasion, pas seulement de parler des dernières nouveautés, mais également de retracer un petit historique du projet.

Swift succède à un projet interne de chez Rackspace. L'objectif : fournir du stockage objet pour l'offre cloud public, garder une rétrocompatibilité avec l'ancien projet interne, mais résoudre les problèmes de passage à l'échelle. Dès 2010 et peu avant la création d'OpenStack, Swift est donc en production chez Rackspace.

Depuis, nombre de fonctionnalités ont été développées et intégrées chaque année. Par ordre chronologique, on peut citer : expiration des objets, multi-régions, storage policies, erasure code, chiffrement, liens symboliques, etc.

Aujourd'hui, Swift 2.21.0 sort avec OpenStack Stein. Des challenges et des évolutions sont toujours à l'ordre du jour, le développement est actif, les utilisateurs sont présents. On peut noter que le support de Python 3 a notamment permis de découvrir plusieurs bugs dans Python lui-même.

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23635/swift-project-update

Nova project update

Nova est un des premiers projets OpenStack et fut release avec la première version d'OpenStack, Austin. Selon le dernier sondage utilisateurs, 82% des clouds OpenStack utilisent Nova. Stein, la dernière release, compte 223 contributeurs.

Cette release apporte sont lot de nouveautés comme l'amélioration de la tolérance de panne des cells : il est maintenant possible de lister les instances d'une cell même lorsque celle-ci est injoignable via les informations stockées dans l'API. On notera également la possibilité de spécifier différents types de volume dans le cas d'un boot from volume.

Beaucoup de travail a été effectué sur l'API Placement, celle-ci a été extraite de Nova et sera complètement retirée lors de la prochaine release : Train. L'API Placement permet maintenant d'exposer les fonctionnalité des computes nodes via des traits. Les traits décrivent des caractéristiques qualitatives d'une ressource, par exemple un type de disque sur un compute node (ssd vs hdd). Placement permet également de configurer les allocation ratio pour l'overcommit directement via l'API en plus de nova.conf.

Des améliorations sont également présentes du côté de la live migration qui est maintenant supportée pour le driver VMware. Stein permet également de chiffrer nativement les flux de live migration via TLS avec QEMU.

La communauté travaille déjà sur les nouvelles fonctionnalités de Train, la prochaine release majeure d'OpenStack. L'accent est toujours mis sur l'API Placement avec :

• Le support de multiples modèles de CPU.
• La synchronisation avec les différents outils de déploiement afin de déprécier placement dans Nova.
• L'intégration avec Cyborg qui fournit des services d'accélération tels que FPGA, CPU, etc.
• La possibilité de forcer le scheduling sur un compute node sans outrepasser les filtres Nova.
• Le support des TPM (Trusted Platform Modules) qui permet aux applications de stocker certaines données sensibles.

À cela viennent se rajouter d'autres travaux en cours :

• La possibilité de rebuild une instance en boot from volume.
• Dépréciation de rootwrap en faveur de oslo.privsep.
• Support de live_migration_permit_post_copy et live_migration_permit_auto_converge par instances en plus du mode global dans nova.conf.
• Remplacer les paquets python python-$(service)client par le SDK OpenStack.
• Support de multiples backends pour Glance.

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23632/nova-project-update

Rook

Cette présentation s'éloigne quelque peu des projets de la Fondation OpenStack puisqu'il concerne Rook et Kubernetes, deux projets faisant partie de la Cloud Native Computing Foundation.

Rook est un projet visant à déployer Ceph au sein d'un cluster Kubernetes. Ceph est basé sur une architecture plutôt complexe et le déployer et le maintenir n'est pas chose aisée. Grâce aux primitives de Kubernetes, un des objectifs est de fournir une méthode de déploiement simple et efficace. Un des autres objectifs est de profiter des fonctionnalités de Kubernetes comme l'autoscalabilité horizontale et l'autohealing pour apporter de la résilience à Ceph. Ces fonctions existent bien entendu aussi au sein d'OpenStack, mais elle sont moins souvent mises en oeuvre. De plus, étant un projet de la CNCF, Rook se déploie dans des conteneurs.

Ceph pouvant être considéré comme une simple application, il n'y a aucun raison de ne pas le déployer dans des conteneurs et de bénéficier des mécanismes de healthcheck, autohealing, rolling update offerts par Kubernetes. A cela s'ajoute les capacités natives de Ceph à répliquer ses données et ainsi obtenir une solution de SDS performante, résiliente, scalable et facilement maintenable.

Actuellement, Rook gère le failover des Monitors Ceph, le récupération de la perte d'un OSD (dans certaines conditions précises malheureusement), la mise à jour via rolling update de Rook lui même ainsi que de Ceph (d'une version majeure à la suivante).

Dans les futurs développement de Rook, les principaux points d'amélioration concerneront :

• le renforcement de la sécurité réseau
• l'intégration du dashboard Ceph
• l'intégration à Airship

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23237/rook-a-new-and-easy-way-to-run-your-ceph-storage-on-kubernetes

Heat : project update

En introduction, rappelons que Heat est le service d'orchestration historique d'OpenStack. Il permet de décrire et de paramétrer, dans des fichiers YAML, des infrastructures virtuelles composées de ressources OpenStack. Ces fichiers YAML, nommés "templates", permettent également de spécifier les relations et les inter-dépendances entre les différentes ressources composant la "stack", qui n'est rien d'autre que la forme dynamique d'un template, son instanciation en quelques sortes. Associé aux services de télémétrie et d'alerting, Heat permet également de mettre en oeuvre des mécanismes d'auto-scaling de groupes d'instances.

Rico Lin, de l'entreprise chinoise EasyStack, et Zane Bitter de Red Hat nous présentent en une vingtaine de minutes les nouveautés de Heat d'ores et déjà disponibles dans la release Stein d'OpenStack ainsi que les principales orientations décidées pour la release en cours de développement, Train. Au passage, Rico et Zane nous précisent que le projet Heat est maintenant géré sous l'outil collaboratif Storyboard.

Nouveautés dans la release Stein :

• une toute nouvelle fonctionnalité marquante : le support du multi-cloud via la nouvelle ressource "OS::Heat::Stack".
• la propriété "personality" de la ressource Nova:Server est dépréciée. Il faut maintenant utiliser user_data et/ou metadata.
• les ressources Octavia supportent à présent le protocole UDP.
• upgrade : une nouvelle commande fait son apparition, "heat-status upgrade check", pour réaliser les vérifications nécessaires avant de passer de version n en version n+1.

Nouvelles propriétés :

• Neutron::Quota : rbac_policy et subnetpool
• Neutron:ProviderNet : tags

Nouvelles ressources

• Blazar: Host, Lease
• Glance : WebImage (image dont la seule méthode d'importation est web-download)
• Neutron : plusieurs nouvelles ressources qu'il serait laborieux d'énumérer ici.

Orientations décidées pour la release Train :

• ressource pour le service Vitrage
• amélioration des mécanismes d'auto-scaling et de notifications
• enrichissement de la documentation

À noter également la création du SIG (Special Interest Group) "Auto-Scaling".

Et enfin, le nom de la distribution devient "openstack-heat" (contre "heat" auparavant).

Heat reste un service incontournable pour orchestrer des infrastructures virtuelles sur un ou plusieurs clouds OpenStack tout en profitant pleinement de ce qu'il y a de meilleur parmi tous les services unitaires qui composent le bouquet OpenStack. Et, encore en 2109, il reste un des projets les plus dynamiques de la communauté OpenStack.

Forum

Ironic SIG

Ironic est le service bare metal d'OpenStack, mais il est possible de l'utiliser en stand alone en dehors d'OpenStack.

Pour rappel, Ironic était a l'origine un driver comme un autre pour Nova, c'est à dire qu'il permettait d'utiliser les ressources physiques (serveurs) comme des instances. Aujourd'hui il s'est plus dirigé vers le management de ces ressources, comme le montre les retours d'expérience du CERN ou Plateform9. Le CERN utilise Ironic depuis 18 mois pour manager ses nouveaux serveurs (environ 2000).

Le Summit a permis de réunir les développeurs et les utilisateurs afin que ces derniers apportent leur retour d'expérience et les points d'améliorations à apporter, parmi ceux-ci on peut citer:

• Besoin d'une matrice de compatibilité hardware
• De la documentation sur les fonctionnalités supportées de chaque drivers
• À grande échelle, mieux supporter le taux d'erreur que peut avoir le hardware.

https://etherpad.openstack.org/p/DEN-bare-metal-SIG