#OpenStackSummit #osones #berlin #frenchies #teamOsones #OpenStack-fr

A post shared by Osones (@livinthecloud) on Nov 14, 2018 at 4:51am PST

Keynotes

Deuxième journée qui démarre comme à l'habitude par des keynotes. Ce matin il est question notamment des nouveaux projets non-OpenStack chapeautés par la Fondation : Zuul, Airship, ou encore StarlingX.

Mark Collier, COO de la Fondation, annonce que le deuxième Summit de 2019, également le deuxième appelé Open Infrastructure Summit, se tiendra en Chine. La ville choisie et plus de détails seront publiés dans les prochaines semaines.

Keynote room #OpenStackSummit pic.twitter.com/6BQTaosJIU

— Adrien Cunin (@Adri2000_OS) 14 novembre 2018

Breakout sessions

LBaaS : Migration de Neutron à Octavia

Il est temps de migrer ! Le load-balancer historique Neutron LBaaS est déprécié depuis la release Queens d'OpenStack, son retrait est prévu pour la version U d'OpenStack qui sortira en Septembre 2019 (neutron-lbaas et neutron-lbaas-dashboard).

L'objet de cette présentation était de fournir la liste exhaustive des méthodes de migration de Neutron LBaaS vers Octavia, mais revenons d'abord sur la description du service : nous en avons parlé hier, le service de load-balancing d'OpenStack est un self-service de haute disponibilité instanciable à la demande, scalable, agnostique à l'application et à sa plateforme. Créé pendant le développement de la release Juno, il compte dans sa dernière release 99 contributeurs issus de 30 entreprises différentes. Autrefois sous-projet de Neutron, le composant réseau d'OpenStack, il est désormais devenu un projet à part entière sous le nom d'Octavia.

Plusieurs chemins de migration sont proposés :

• Utilisation d'un driver Octavia pour Neutron en parallèle du driver legacy
• Utilisation d'un plugin proxy en mode pass-through pour forwarder les requêtes vers le endpoint de l'API d'Octavia
• Utilisation de règles de redirection couche 7 pour rediriger les calls API vers Octavia
• Migration à chaud via des outils dédiés comme nlbaas2octavia

KataContainers vs gVisor : Benchmark des deux outils

Kata Container et gVisor sont deux container runtimes tout comme runc, avec une orientation sécurité forte (on parle de secure containers). Les deux sont compatibles avec les spécifications du standard OCI, donc avec Docker, Kubernetes, etc.

Kata Container

Initié par Hyper.sh et Intel, Kata Container est basé sur des technologies de virtualisation hardware, tout comme les machines virtuelles. Il est hébergé par la Fondation OpenStack et compte dans ses contributeurs des entreprises comme Huawei, Google, ou MSFT. L'outil propose deux niveaux d'isolation : KVM et l'utilisation d'un mécanisme de protection du ring CPU. Sa particularité est de proposer plusieurs méthodes natives pour l'optimisation des I/O (passthrough, vhost, vhost-user...).

gVisor

Développé par Google et open sourcé depuis mi-2018, gVisor est un runtime écrit en Go fonctionnant côté user-space. Il réimplémente une portion du système Linux. L'isolation est localisée sur deux couches :

• Via un petit kernel guest écrit en go (attention, cette méthode bien que sécurisée peut poser des problèmes de compatibilité)
• Via un mécanisme de ring protection et l'utilisation d'un nombre restreint de syscalls.

Ces syscalls peuvent être interceptés avec KVM ou ptrace. Les opérations sur les fichiers sont traitées via un process gofer séparé.

Comparaison et benchmarks

• Côté sécurité, les deux outils incluent une isolation par couche, ce que ne fait pas runC. Leur surface d'attaque est restreinte.
• Kata Container pose moins de problèmes de compatibilité que gVisor
• Côté performances, match nul sur l'overhead CPU ou mémoire. On peut juste noter que gVisor démarre plus rapidement avec un impact mémoire moins lourd. À ce niveau, les performances sont sensiblement similaires à celles de l'hôte.
• En revanche gVisor réagit (très) mal sur une utilisation intensive de syscalls. Petite catastrophe sur les performances réseau de gVisor à l'heure de la rédaction de l'article qui, en mettant le focus sur la sécurité reste est très loin derrière Kata Container. Un benchmark réseau sur une interconnexion 10Gb démontre une incapacité pour gVisor de dépasser 1 Gbps quand runc et Kata Container avoisinent les 9 Gbps. On retrouve un écart similaire sur les performances d'écriture de petits fichiers. L'impact peut être très lourd dans un cas d'usage réel. A titre d'exemple, un AB testing exécuté sur un container NGINX ab -n 50000 -c 100 s'exécutant en 3 secondes pour runc ou Kata Container prend plus de 161 secondes côté gVisor...

gVisor doit continuer à travailler pour améliorer sa compatibilité et rattraper Katacontainer et runc..

Diversity networking lunch by Intel

Pour une fois nous n'allons pas parler d'une conférence mais d'un déjeuner pour promouvoir la diversité au sein d'OpenStack. Nous n'allons pas nous attarder sur la qualité du poulet au curry ni même vous parler de ces délicieuses petites mousses chocolat gingembre mais plutôt sur les personnes qui étaient présentes et les discussions qui ont eu lieu à table.

Le but de la rencontre était de faire le point sur la diversité et sur comment cette diversité est acceptée au sein d'OpenStack. Beaucoup de figures importantes de la fondation mettent un point d'honneur à ce que aucune discrimination ne puisse avoir lieu dans la communauté. Que ce soit pendant les Summits ou simplement dans les outils de travail comme les mailing lists ou IRC. Ce sujet est de plus en plus traité dans le monde de l'IT d'ailleurs: la plupart des projets open source ont même leurs propres groupes "Women of..." ou "Diversity for ...". C'est d'ailleurs le groupe "Women of OpenStack", avec le soutien d'Intel, qui a organisé cette session. Certes, le public était très majoritairement féminin mais pour la première fois l'événement était ouvert à quiconque intéressé par le sujet de la diversité. Certains hommes ont donc aussi pu prendre part aux discussions.

Selon les âges et les provenances des intervenants, les expériences ne sont pas du tout les mêmes, mais tous les témoignages convergent pour dire que dans OpenStack, les différences de genre ou d'origine ne se ressentent pas, ce qui par ailleurs est très encourageant pour une jeune OpenStackEUSE comme moi ! Autre point remarquable : lors des tours de table nous avons entendu l'anecdote suivante : "J'étais au booth de mon entreprise, seule femme, et quelqu'un m'a posé la question suivante : "Est-ce que je peux parler avec un ingénieur ?" La réaction du membre de la Fondation assis à notre table a été de l'indignation. Ce genre de comportement machiste pour lequel une femme ne pourrait pas être autre chose que booth babe n'est plus toléré par la Fondation !

Ce genre d'événement a lieu à chaque Summit et il y a plusieurs groupes discutant de ces questions, alors n'hésitez pas à participer !

OpenStack-Ansible update

OpenStack-Ansible est le projet préféré d'alter way Cloud Consulting quand il s'agit de déployer un cloud OpenStack. Nous sommes contributeurs sur ce projet depuis quelques releases et c'était donc normal pour nous d'assister à cet update.

Le premier constat concerne la diversité des contributions. En effet Rackspace qui était à l'origine de 75% des commits sous Ocata est descendu à moins de 30% sur Rocky. OpenStack-Ansible ne peut plus être considéré comme "single-vendor", 8 sociétés se partageant 80% des contributions, 10% venant de développeurs indépendants et les 10% restants étant éparpillés entre diverses petites sociétés, dont alter way Cloud Consulting. Le nombre de contributeurs est lui aussi en augmentation avec 118 pour la release Rocky.

Les nouveautés pour la version Rocky sont :

• Le support d'Ubuntu 18.04
• Réduction du nombre de variables. Ce changement a mené à une réduction de 25% du temps de déploiement
• Upgrade Ansible 2.5
• Introduction de systemd-nspawn en remplacement de LXC
• Des nouveaux rôles pour Masakari, Panko, Congress et Blazar
• Simplification de l'inventaire

Pour Stein :

• Amélioration du travail d'i18n, notamment avec une traduction allemande (nous sommes à Berlin tout de même !)
• Amélioration de la stabilité sur CentOS
• Travail en commun avec l'équipe TripleO sur les tests de Tempest

Zuul project update

Pour rappel la version 3 de Zuul a été annoncée à Vancouver , il y a 6 mois. Depuis, le projet est devenu un "pilot project" de Open Infrastructure. Zuul est utilisé depuis maintenant 6 ans. La version 3 est partie de la volonté de le faire porter en dehors d' OpenStack car le projet dispose d'une vraie reconnaissance de la communauté.

Les nouveautés de Zuul sont :

• Python 3 exclusivement
• Ansible est le "job execution engine"
• Réécriture de la l'interface web
• Image à chaque release disponible sur DockerHub
• Kubernetes support : utiliser Kubernetes pour avoir des workers. Possibilité aussi de demander un POD ou un namespace vide pour le testing
• Pause job : par exemple besoin d'un registry, Zuul lance le container puis le pause pour que d'autres pipeline utilise cette Docker registry. Une fois les autres jobs finis, le premier job peut reprendre et terminer cette Docker registry

Roadmap :

• Plusieurs version de Ansible peuvent être utilisées dans les jobs. Exemple : OpenStack Ansible a besoin de tester plusieurs versions d'Ansible pour ses rôles
• Driver pour nodepool, OpenShift, Azure et EC2 en review
• Gitlab driver

Pour les développeurs, Zuul est prêt pour la production ce qui n'était pas le cas au dernier Summit. Des utilisateurs ont remonté le point que peu d'informations étaient disponibles sur le déploiement de Zuul, les recommandations etc. Les développeurs indiquent qu'un effort supplémentaire sera fait sur la documentation mais que le produit est suffisamment mature et scalable. On notera que BMW a déployé Zuul sur Openshift.

Neutron-to-Neutron: interconnecting multiple OpenStack deployments

Thomas Morin d'Orange Labs nous présente l'implémentation de BGPVPN pour Neutron sur laquelle son équipe a contribué au cours des dernières années, et la démarche de conception suivie.

Comment faire pour que deux instances situées sur deux clouds différents puissent communiquer entre elles ? L'interconnexion entre deux clouds doit respecter certains principes :

• L'isolation doit être préservée : si les 2 parties ne sont pas d'accord, il ne faut pas qu'il y ait d’interconnexion (symmetric link check)
• Les échanges API entre les 2 instances de Neutron doivent être authentifiés

Dans la présentation il n'est pas question des tunnels IPsec qui introduisent un overhead évitable et non souhaitable dans certaines situations.

Plusieurs techniques d’interconnexion sont possibles, mais le design doit rester agnostique à la technologie sous-jacente, via l'utilisation de driver. Prérequis important : l'implémentation doit proposer une connectivité L2 et L3 avec une forte isolation.

Parmi les solutions disponibles on distingue :

• VXLAN handoff
• VXLAN GW
• BGP VPN
• GRE

La récupération des paramètres de l’échange se fait soit par fichier de configuration (simple), soit par négociation (rajoute de la complexité dans l'implémentation)

Un exemple de technique d'interconnexion sont les BGP VPNs qui d'ailleurs sont déjà implémentés dans Neutron (Neutron BGPVPN, qui peut être spécifié dans neutron.conf router_driver=bgpvpn ). Par ailleurs cette technique est utilisable avec la plupart des solutions SDN (OVS, Contrail, OpenDaylight, Nuage).

Démo : Interconnexion entre un cloud appelé Mars et un cloud appelé Pluto identiques grâce à BGP VPN. BGP VPN va créer de nouvelles routes afin de permettre aux VMs de Mars de communiquer avec les VM de Pluto. openstack interconnection create en spécifiant l'adresse du Keystone, les identifiants des réseaux à connecter et enfin le niveau réseau pour la connexion (L3 par exemple). L'interconnexion prend quelques secondes à se mettre en place, et ensuite... le ping partant d'une VM de Mars va atteindre la VM de Pluto !

Ceph is great for OpenStack and you should use it ! Groupe de travail - Chris Morgan, Cloud builder chez Bloomberg

Animée par Chris Morgan, un ingénieur Cloud de Bloomberg, cette session est une discussion ouverte, orientée retour d'expériences et partage de réflexions, autour de la technologie Ceph.

Ceph est une technologie logicielle Open Source de niveau "entreprise" offrant des services de stockage niveau bloc, objet et systèmes de fichiers Posix. Ceph est très populaire et s'appuie sur une communauté très active. Ceph, qui se déploie sous forme de cluster comportant des noeuds contrôleurs et des noeuds de stockage, est notamment apprécié pour ses capacités en termes d'autonomie et de résilience aux pannes courantes : défaillance d'un serveur, d'un périphérique de stockage,...

Un autre aspect de Ceph ayant largement contribué à son adoption est la "Rados gateway" : une interface programmatique permettant de s'adresser à Ceph, au-dessus d'HTTP, en utilisant la sémantique de S3, le service de stockage objet d'Amazon Web Services.

Côté déploiement, un administrateur Ceph présent dans la discussion indique que l'utilisation d'OSA pour déployer un cluster Ceph est un peu douloureux mais les playbooks Ansible pris unitairement fonctionnent très bien. Un autre administrateur indique que, pour sa part, il a fait le choix de déployer un cluster Ceph avec Kolla et qu'il ne le regrette pas !

Mais quid des performances ? Disons que Ceph peut mieux faire. Pour le moment, il n'est pas le champion de la compétition et son optimisation en matière de performances n'est pas aisée.

Enfin, quelques exemples d'implémentation en production sont décrites sous leur aspect matériel :

• pour le stockage "tiède" et le stockage "froid", à base de disques bon marché de grande capacité : serveurs Xeon D 1U + 12 HDD Helium 3,5" et un réseau de 2x10GbE. L'administrateur Ceph qui fait part de cette expérience précise que ce type de plate-forme est très intéressante du point de vue consommation d'énergie.

• autre exemple, pour un stockage mixte cette fois : serveurs ARM 64 (Qualcomm, Cavium, HiSilicon) + SSD et HDD.

Un autre utilisateur de Ceph rappelle que la migration HDD vers SSD peu se faire progressivement.

En savoir plus : https://ceph.com/cephdays/ceph-day-berlin (vous y trouverez notamment la description d'un cluster à 55 noeuds gérant une capacité de stockage de 55 peta-octets).

Forum

Plusieurs sessions aujourd'hui ont traité de sujets intéressants.

Améliorations Boot From Volume

L'une d'elle concernait la fonctionnalité de Boot From Volume (BFV) de Nova : la possibilité d'utiliser une ressource du stockage block (un volume) comme disque racine d'une instance et donc y stocker l'OS et les éventuelles données attenantes de manière sûre. Même si elle n'est a priori que peu dans la philosophie cloud-compliant, la fonctionnalité est utilisée par nombre d'utilisateurs et ce malgré quelques limitations toujours d'actualité plusieurs années après son implémentation initiale. Ce sont notamment ces limitations qui ont été abordées dans cette session, afin de préparer les prochaines étapes d'amélioration. Citons par exemple :

• La possibilité de choisir un type de volume directement à la création d'une instance en boot from volume
• La possibilité d'utiliser l'action de rebuild sur une instance en boot from volume

Récemment (version Rocky), c'est un comportement longtemps regretté par les opérateurs de clouds OpenStack qui a finalement été corrigé : le champ "disk size" d'un type d'instance n'est plus pris en compte dans l'ordonnancement des instances en boot from volume, cela n'avait en effet pas de sens.

En vrac

• Une session de réflexion sur la manière dont OpenStack expose ses projets et ses livrables : plusieurs sections du site web notamment devraient être améliorées afin de fournir plus directement les informations attendues par les utilisateurs finaux ("à quoi sert le projet X ?").
• Une session de discussion sur ce que l'équipe OpenDev doit dorénavant faire ou ne pas faire : l'équipe OpenDev est le successeur de l'équipe OpenStack Infra - en réalité la même équipe qui élargit sa base d'utilisateurs potentiels au-delà d'OpenStack uniquement, toujours dans l'optique Open Infra portée par la Fondation.
• Une session plus technique sur la possibilité, inexistante à l'heure actuelle, de supprimer un project/tenant dans un cloud OpenStack et ainsi supprimer de manière automatique l'ensemble des ressources s'y rapportant. Extrêmement demandée par tous les opérateurs de cloud OpenStack (nous y compris), ce n'est évidemment pas une mince affaire à implémenter, tant les cas particuliers peuvent être nombreux au travers des interactions entre les différents services OpenStack. Il faudra peut-être du temps pour voir la fonctionnalité arriver dans nos clouds OpenStack en production, mais le sujet est en tout cas sur la table !