Après Vancouver, Tokyo, Austin, Barcelone, Boston et Sydney, c’est de nouveau à Vancouver que nous nous retrouvons pour l'édition 2018 de l’OpenStack Summit ! Comme toujours, Osones vous propose un retour sur les faits les plus marquants de ce 17ème summit OpenStack !

• Vers le jour 2
• Vers le jour 3
• Vers le jour 4
  

Keynotes

Cette première matinée de keynotes donne le ton de cet OpenStack Summit qui s'oriente clairement vers le monde de l'Open Infrastructure, c'est-à-dire l'ensemble des logiciels libres, issus de différentes communautés (notamment celle des Fondations OpenStack et Cloud Native Computing), permettant de construire des infrastructures et plate-formes IT.

Le cloud se diversifie par les différents besoins applicatifs mais également par les besoins hardware (architectures x86 / ARM / GPU / FGPA), ce qui conforte la place de cette Open Infrastructure.

Quelques évolutions récentes d'OpenStack ont également été abordées. Le support des vGPUs par le composant de Compute Nova, par exemple. Également les travaux sur le Fast Forward Upgrade ou l'Extended Maintenance Support. À partir de la version Ocata, les branches stables pourront accueillir des correctifs pendant 18 mois après la fin officielle du support (elle-même 18 mois après la sortie initiale). Il s'agit de la période d'extended maintenance. La différence avec la période de support déjà existante ? Aucune stable release.

Quelques chiffres à retenir de cette keynote :

• 71% des services providers utilisent OpenStack
• pour l'année 2018, le marché est estimé à 6,1 milliards USD
• il y a aujourd'hui plus de 10 000 000 de cores en production sous OpenStack

On retiendra également l'intervention de Mark Shuttleworth (Canonical) qui a ouvertement taclé les prix pratiqués par Red Hat avec un slide comparant les coûts d'une plate-forme Canonical vs RedHat.

Keynote : un focus sur Zuul V3

Moteur de CI Open Source, scalable, 80 contributeurs, 4.200 commits
dernière version stable V 3.03
devise/objectif : "Stop merging broken code !"
80 contributeurs et 4200 commits

La keynote est également l'occasion d'un update sur le composant Nova. On nous rappelle que depuis la version Ocata d'OpenStack, un upgrade du service Nova est aussi simple que :

• arrêter le control plane (les VM continuent de tourner)
• exécuter un db sync
• migrer les données
• relancer le control plane

Keynote : Overview de Kata Containers

Ils combinent la rapidité et la légèreté des conteneurs avec la sécurité (cloisonnement) des machines virtuelles.
L'autre idée est de faire tourner les conteneurs dans des VM "light" afin qu'ils ne partagent pas le même noyau Linux.
Le code d'origine a été versé par les entreprises Intel et Hyper.sh et l'on compte 35 contributeurs et 1250 commits à ce jour.
Dernière version stable : Kata Containers V1.0 22/05/2018

L'équipe projet encourage fortement les nouvelles contributions

en savoir plus :

• https://katacontainers.io
• Notre article de la KubeCon

Breakout Sessions

CERN experiences with Multi Cloud, Federated Kubernetes

Pour faire suite à sa brève démonstration en Keynote, Ricardo ROCHA du CERN nous présente plus en détails la fédération de clusters Kubernetes.

Les use cases du CERN reviennent souvent, que ce soit dans la communauté OpenStack ou dans celle de Kubernetes. En effet, leurs besoins collent parfaitement à la philosophie cloud. Comme nous en avons déjà parlé à l'occasion des précédents summits, le LHC (Large Hadron Collider) fait percuter deux protons entre eux à des vitesses proches de celle de la lumière. Les détecteurs chargés de relever les informations de la collision génèrent des data brutes de l'ordre du Peta-octet par seconde. Une quantité de données complètement démentielle qui est tout d'abord filtrée pour retomber au niveau de 1-10Go/s. Cette quantité de données reste néanmoins relativement importante et le CERN se sert d'une capacité de calcul distribuée répartie dans plus de 200 sites à travers le monde de façon à accélérer le traitement de ces données. C'est dans ce contexte de calcul distribué que le besoin de clusters Kubernetes fédérés naquit. A noter que cette infra est actuellement composée de 700 000 coeurs, fait tourner plus de 400.000 jobs et possède une capacité réseau de 240 Gb/s.

Pour la démonstration, l'infra "multi cloud" fédère des clusters Kubernetes sur les plate-formes privées du CERN, sur GCP (avec GKE) et T-System.

Quelles sont les motivations qui ont poussé le CERN à vouloir fédérer des clusters ?

• Absorber des pics de charge périodiques
• Simplifier le monitoring, la gestion du cycle de vie et l'alerting
• Faciliter leur déploiement grâce à une API uniforme, de la réplication et les load-balancers

Le déploiement des clusters s'appuie sur Magnum qui permet (à la manière de GKE) de déployer "en un clic" des clusters Kubernetes. L'utilisation de Magnum permet la réutilisation des crédentials Magnum, la capacité à ré-utiliser le concept des tenants ainsi qu'un paramétrage plus ou moins fin de la configuration du cluster Kubernetes. La création d'une fédération demande de nombreux échanges de clés et Magnum facilite ces échanges car il connaît lui même les clés (créées à l'instanciation).

En conclusion :

La fédération de clusters est prête dans Kubernetes. Magnum supportera la fédération de clusters dans la release Rocky, le code est prêt et est actuellement en review. Utilisé par le CERN en production (en débutant par les applications legacy, puis en l’étendant aux applications cloud native). Très bon support des communautés OpenStack et Kubernetes, notamment au travers du SIG commun entre les deux communautés.

Forum

Parmi les multiples sujets abordés lors de cette première journée de Forum (discussions développeurs/opérateurs) :

• Définition de rôles Keystone par défaut, au-delà des deux actuellement existants
• Continuation de la migration des projets vers Storyboard, notamment pour la gestion des rapports de bugs
• Question de l'utilisation du service de Placement dans Cinder
• Points restant à traiter pour officiellement supprimer le support de Python 2 au profit de Python 3

Mais également :

Octavia onboarding

Petite session de onboarding, pour ceux qui ne connaissent pas Octavia, il s’agit du "new and improved" Neutron LBaaS.

Petit historique : Neutron LBaaS v1 est maintenant déprécié depuis un petit moment (Liberty), son successeur, Neutron LBaaS v2 l'est également depuis Queens. Plus d'infos sur le sujet

L'implémentation de base de Neutron LBaaS v2 est un driver HAProxy fonctionnant sur le control plane d'un cloud OpenStack, cette solution n'est malheureusement ni scalable, ni hautement disponible. C'est pour palier à ce manque qu'Octavia a été créé.

Octavia dispose de deux API, la V1 et la V2. L'API v1 est une API compatible avec Neutron LBaaS v2 et a été conçue pour être utilisée via l'API Neutron. L'API v2, qui est maintenant la version stable et recommandée, est une API standalone, avec son propre endpoint et client, qui superset l'API neutron-lbaas V2 maintenant dépréciée.

Octavia fournit du Load Balancing as a Service, de manière scalable, TCP/HTTP, terminaison TLS, active/passif load balancing et bientôt actif/actif.

Octavia supporte un système de drivers afin d'implémenter le load balancing, comme le faisait Neutron LBaaS V2, permettant à différents fournisseurs de proposer leurs propres drivers, à partir de spécifications établies.

L'implémentation officielle d'Octavia est faite à partir de différents composants :

Sans trop entrer dans les détails, l'implémentation se base sur des VM de services HAProxy appelées "Amphora" qui fournissent une API de configuration, cette API étant pilotée par le control plane d'Octavia.

Pour l'instant les Amphorae (latin oblige...) sont des instances Nova, mais le support de machines bare metal ou de conteneurs est en projet. Pour le moment, les instances fonctionnent en actif/passif. Bien que pas entièrement scalable, on atteint tout de même un meilleur niveau de haute disponibilité. Le support actif/actif est également dans les cartons.

Petit point sur l'API, Octavia s'intègre à la CLI OpenStack :

  ...
  loadbalancer amphora list
  loadbalancer amphora show
  loadbalancer create
  loadbalancer delete
  loadbalancer failover
  loadbalancer member set
  loadbalancer member show
  loadbalancer pool create
  loadbalancer pool delete
  loadbalancer pool list
  ...

Et pour ceux qui ont déjà utilisé Neutron LBaaS V2 et tenté de supprimer un load balancer, et se sont rendus compte qu'il faut tout supprimer à la main (listener, pool, healthmonitor, etc.) et dans l'ordre, on notera l'ajout de la killer feature pour supprimer tous les composants d'un load balancer en cascade :

openstack loadbalancer delete --cascade 013989c1-6e97-4ba9-b66d-bd630f9896fd

OpenStack Ansible: Project update

Point sur le projet OpenStack Ansible par le Jean-Philippe Evrard, actuel PTL.

D'abord sur l'évolution de la communauté, on notera que sur certains chiffres (notamment sur le nombre de reviews), la part de Rackspace diminue au profit des contributeurs indépendants et d'autres sociétés. Ce qui en soi est une bonne chose pour l'avenir du projet.

Dans les évolutions à venir, on parle d'optimisation sur l'utilisation des variables pour accélérer les déploiements, modifier la gestion de l'inventaire, passer à Zuul V3 ou encore revoir les scénarios pour le testing.

Au-delà du Cloud "Data Center", le futur de la fondation OpenStack : Thierry Carrez

T. Carrez nous rappelle les objectifs initiaux de la fondation OpenStack :

• open collaboration : personne ne détient à lui seul les "clés du royaume". Autrement dit, personne ne maîtrise à lui seul la destinée de la technologie OpenStack.
• open infrastructure : éviter les oligopoles de fournisseurs d'infrastructure
• upstream et downstream : unifier ces deux domaines d'expertise au sein d'une seule et même entité
• prendre plaisir à participer, à contribuer !

Il nous rappellent également les résultats obtenus par la Fondation :

• une coalition d'organisations, alignées sur les besoins en Infrastructure et qui souhaitent se libérer des géants de l'industrie IT
• une palette d'événements (Summit, PTG, OpenStack Days, meetups)
• une communauté d'utilisateurs
• une infrastructure technique de CI poussée à une échelle inédite à ce jour

Mais, ces 6 derniers mois, la discussion a changé de nature : elle est passée de "project oriented" à "goal oriented". Et les quatre grands sujets suivants ont émergé :

• Data Center cloud
• Edge Computing
• Container oriented infrastructure
• CI/CD

Ce changement de nature a occasionné certains changements sur la stratégie de la Fondation :

• OpenStack ne sera plus la seule technologie hébergée par la fondation
• Le concept d'Open Infra commence à prévaloir, le constat peut être déjà être réalisé ici à Vancouver sur les affiches du Market Place
• La marque "Open Infra" est déjà déposée et peut être utilisée par les différents User Groups
• Les statuts de la Fondation devront évoluer
• L'organisation interne de la Fondation devra également être revue
• L'infrastructure construite pour supporter OpenStack doit évoluer pour accompagner de nouveaux projets, ce qui demandera de repenser les investissements de la Fondation

OpenStack reste la base du concept "Open Infrastructure", mais d'autres technologies seront hébergées par la Fondation.

Néanmoins, le fond reste inchangé et la philosophie qui drive OpenStack depuis 8 ans reste immuable :

• Open Source
• Open Design
• Open Community
• Open Development

Quant à la gouvernance, elle ne doit intervenir qu'en cas de réel besoin de décision. Les différentes communautés doivent pouvoir s'auto-gérer (au travers de différents User Committe et Technical Committee).

A demain pour la suite de l'OpenStack Summit 2018 à Vancouver !

N'hésitez pas à réagir et à nous poser vos questions sur notre compte Twitter @osones. A demain pour la suite de ce qu'il ne faut pas louper !

La Team Osones