Osones vous fait vivre l’OpenStack Summit de Boston comme si vous y étiez !

• Jour 1
• Jour 2
• Jours 3 et 4

Conférences

Neutron : update

Retour sur les blueprints en cours pour Pike. Parmi ces blueprints, on trouve le "Make RBAC domain aware" fait par Kourosh Vivan pour couvrir le besoin d'un de nos clients qui souhaite partager un réseau externe uniquement à un domaine particulier.

Les visions pour Queens sont encore très vagues et il est surtout question des fonctionnalités. Le process pour demander une nouvelle fonctionnalité est le suivant : faire un RFE avec un rapport de bug et expliquer en un paragraphe ce qu'on souhaite, ensuite les développeurs se réuniront pour discuter de l'implémentation (au PTG, au Summit...).

OVN L3 Gateway

La gateway dans le contexte OpenStack est le pont entre le réseau physique et le routeur virtuel.

OVN utilise le même principe de fonctionnement que OVS. Un mapping est donné dans la configuration du host, ce mapping indique quelle interface utiliser pour sortir. Tous les hosts ne sont pas forcément identiques, le mapping peut être différent, c-à-d que certains hosts ne sont pas forcément connectés au réseau externe. Dans le cas de floating IPs, OVN gère le SNAT et le DNAT depuis tous les hyperviseurs possibles après un premier filtrage suivant le mapping. Mais pour le SNAT sans floating IPs, la gestion reste centralisée.

Avec OpenStack, le SNAT de OVN est centralisé. Le host, après une sélection en fonction du mapping, est choisi en fonction du nombre de gateways qu'il héberge déjà.

OpenStack-Ansible : update

Rappel de quelques points sur OpenStack-Ansible (OSA) :

• Le premier POC de OpenStack-Ansible a été réalisé sur Havana
• Le projet a d'abord été hébergé au sein de Stackforge avant de devenir OpenStack depuis Kilo
• Il y a environ 100 contributeurs uniques sur OSA dans la release Ocata

Les objectifs pour Pike sont :

• le support de Centos 7
• déployer tous les services API sur nginx ou uwsgi plutôt que eventlet
• une partie "operation guide" dans la documentation

Question : pourquoi ne pas remplacer LXC par Docker comme d'autres projets ? Pour deux raisons principales, tout d'abord, avoir la possibilité de faire du baremetal. Ensuite parce que la philisophie container n'est pas assez flexible dans certains cas. Par exemple dans les containers, une image doit être faite puis deployée. Et il n'est pas simple de modifier cette image, alors qu'avec LXC les modifications sont possibles à chaud.

OSA dispose aussi d'un dépôt Git où se trouvent des playbooks utiles pour un opérateur de cloud OSA : https://github.com/openstack/openstack-ansible-ops

Firewall as a Service version 2 : un nouveau départ

(Sridar Kandaswamy, Yushiro Furukawa)

Pour mémoire, la version 1 de FWaaS est supportée depuis la release Havana et les règles de filtrage sont appliquées sur les routeurs.

Le projet a été "rebooté" au moment du summit de Tokyo, en octobre 2015, principalement afin de :

• nettoyer et rationaliser le code
• permettre l'application des règles de filtrage sur les ports des instances
• permettre la cohabitation avec les Security Groups

Une nouvelle API est donc disponible depuis la release Newton et permet de manipuler des concepts somme toute assez classiques tels que des règles de filtrage basées sur le type de protocole, sur les IP et ports source et destination, associées à des actions telles que "autoriser" (allow) et "refuser" (deny).

En plus de la notion de "firewall policy" déjà présente en v1, la nouvelle API propose les "firewalls groups", largement inspirés du mécanisme des Security Groups. À propos de Security Groups, notons que, dixit les développeurs, la gestion de la cohabitation a été difficile et que cela a entrainé du retard dans le projet.

L'intégration avec Neutron est intéressante en ce sens qu'elle permet de capter les événements "port create/update/delete", autorisant ainsi l'application dynamique des règles de filtrage, via les "firewall groups".

Côté driver, l'implémentation L3 reste basée sur iptables. Le niveau L2, quant à lui, est géré en tirant parti des "tables de règles" utilisées par OpenVSwitch (OVS). Pour cela, FWaaS utilise les tables 41, 42, 43, 51 et 52 associées au bridge d'intégration (br-int) d'OVS.

Voyons maintenant les principales nouveautés et améliorations prévues dans la roadmap Pike :

• intégrer toutes les fonctionnalités de FWaaS dans le dashboard Horizon
• augmenter la stabilité et les performances
• poursuivre le refactoring du code
• logguer les actions du firewall et maintenir des compteurs

Et les priorités pour la version Queens :

• intégration de technologies "vendor"
• implémentation de la notion de "zone"
• filtrage niveau L4-L7 (ambitieux mais intéressant pour les applications hébérgées qui exposeraient des API et auraient besoin de les protéger...)

Enfin, il est important de noter que la fin de vie de FWaaS version 1 est prévue pour la release Rocky dont le cycle de développement débutera en février 2018.

Cinder : not just for secondary attached storage !

(John Griffith, Netapp)

Cantonner Cinder à son rôle de fournisseur de stockage persistant pour les instances serait passer à côté de son potentiel et se priver par la même occasion de fonctionnalités intéressantes.

Parmi celles-ci, prenons celle qui consiste à utiliser Cinder comme backend de stockage pour le service Image (Glance) en lieu et place de Swift, souvent utilisé pour cela. Drôle d'idée ? Pas tant que ça si l'on se place dans la nécessité de démarrer les instances sur le principe Boot From Volume (BFV) pour, par exemple, réduire au maximum la consommation d'espace sur les disques locaux des compute nodes.

Avec Glance utilisant un backend Swift, le BFV nécessite un transfert de l'image dont la durée se mesure en minute(s). Avec Glance utilisant un backend Cinder, ce transfert est inutile si l'image est déjà présente sur le volume (et si le backend de stockage supporte cette fonctionnalité). Le bénéfice est immédiat : l'opération qui pouvait durer plus d'une minute ne dure plus qu'une poignée de secondes !

Magnifique me direz-vous, mais il faut reconfigurer le service cinder-api côté contrôleur avec les paramètres adaptés au backend !

Et pour parler du futur (proche), voici ce que l'on peut trouver dans le product backlog :

• rendre le BFV automatique et définissable comme le comportement par défaut. L'utilisateur n'aurait donc plus à gérer le BFV explicitement (le disque éphémère fait déjà cela mais il disparait avec l'instance lorsque celle-ci est supprimée)
• introduire le principe au niveau des flavors en leur faisant porter un nouveau "flag"
• introduire la notion de "cinder image backend driver" dans nova

Juste un rappel pour finir : le "live migration" d'instance fonctionne même si celle-ci possède un volume Cinder attaché !

Forum

Octavia : Update

Octavia est le "nouveau" projet de LoadBalancer as a Service d'OpenStack. Celui-ci a débuté comme sous projet du projet Neutron et est depuis quelques temps déjà un projet à part entière. Nous vous parlions déjà d'Octavia il y a un an au Summit d'Austin.
Cette session est l'occasion de faire un point sur les fonctionnalités attendues pour Pike ainsi qu'un aperçu de celles prévues pour Queens et Rocky.

La version Pike d'Octavia représente 65 contibuteurs venant de 28 entreprises différentes et ce projet reste parmi les composants les plus attendus par la communauté OpenStack.

Voici donc un résumé des fonctionnalités qui seront présentes dans Pike, ainsi que celles qui devraient arriver avec Queens :

Pike :

• Merge de l'API v2 Neutron LBaaS vers l'endpoint de l'API v2 d'Octavia
• Support d'Octavia dans la CLI OpenStack
• Support pour le déploiement d'Octavia avec OpenStack-Ansible et TripleO

Queens :

• Haute disponibilité active/active
• Choix des flavors pour les load balancers
• Amélioration de l'intégration d'Octavia avec le dashboard Horizon

En terme d'orientation, Pike sera une release centrée sur la sécurité et l'UX tandis que Queens, tout en continuant à se concentrer sur l'UX, abordera les problématiques de scalabilité et d'interoperabilité. La scabalité est en effet un des points essentiels pour Octavia qui vise à être un "carrier-grade" load balancer.

Kubernetes on OpenStack

Cette session fait un petit tour d'horizon des différentes méthodes de déploiement de Kubernetes sur OpenStack.

Il existe beaucoup d'outils afin de déployer Kubernetes sur OpenStack, d'après les personnes présentes, ceux sont Magnum (projet integré à OpenStack et Kubeadm (la solution "officielle" de Kubernetes).

L'avantage de Magnum est d'être intégré à OpenStack et ses composants (utilisation de Heat pour provisionner des clusters Kubernetes). Là où Kargo utilise Ansible et/ou Terraform. Deux méthodes plutôt "opinionated" donc. L'avantage de Kargo est de supporter de multiples cloud providers et de pouvoir provisionner des cluster ailleurs que sur OpenStack, par example.

Kubernetes dispose de la notion de "cloud provider" qui permet de s'intégrer à differents types de cloud (AWS, GCP, OpenStack, etc). Peu de personnes l'utilisent pour le moment mais cela permet :

• L'integration avec Cinder pour créer des volumes Kubernetes.
• L'intégration avec Neutron LBaaS pour créer des services Kubernetes.

Sans ces intégrations, l'exploitation de Kubernetes est relativemnt difficile puisque des solutions alternatives doivent être utilisées. Il est tout de même plus intéressant de pouvoir utiliser les fonctionnalités existantes d'OpenStack.

Le support de cloud provider est actuellement en développement dans Magnum pour CoreOS et Atomic et devrait être disponible pour Pike.

Soirée francophone de l'association OpenStack-Fr

Comme à chaque Summit, OpenStack-fr a rassemblé un maximum de francophones présents à Boston pour la traditionnelle photo de groupe.

Merci à tous ceux qui ont pu passer pour la photo du Summit de Boston, rendez-vous ce soir pour la soirée OpenStackFR #OpenStackSummit pic.twitter.com/KKLw5QlO2u

— OpenStackFr (@OpenStackFr) 10 mai 2017

Nous nous sommes également réunis le soir dans un restaurant à deux pas du centre de conférence afin de se retrouver entre OpenStackers francophones. Nous nous sommes retrouvés à une vingtaine de francophones chez Joe's (qui servent des Ribs qui nous ont fait saliver).

Virtual Client Computing VDI sur OpenStack

Osones a déjà été confronté à un besoin de VDI chez un client. Le besoin, fournir à ses utilisateurs (développeurs, métiers) des environnements web totalement sécurisés et indépendants du système d'information. Niveau architecture, un cluster OpenStack se situe en DMZ et propose du VDI permettant de naviguer sur le web sans aucun filtre.

Aujourd'hui, le marché du VDI est dominé par des technologies matures et propriétaires, appartenant à VMWare, Critrix, et Microsoft.

Pourquoi faire du VDI sur du cloud ?

Les utilisateurs n'ont pas tous les même besoins. Chez Osones, nous nous en rendons compte déjà à notre échelle avec de simples commandes de Laptops. Certains ont besoin de 16 Go de Ram pour les formations OpenStack, d'autres un CPU plus puissant pour leurs applications lourdes. La gestion des configurations hardware est assez complexe et parfois source de conflit.

Les technologies de VDI permettent de diversifier les configurations, et d'apporter l'élasticité au niveau du poste de travail, comme nous la connaissons pour les serveurs. Avec ces technologies, faire du burst sur un poste de travail est tout à fait possible. Ainsi, le service rendu à l'utilisateur est plus diversifié et mieux ajusté aux besoins réels des utilisateurs.

Pourquoi OpenStack pour faire du VDI ?

OpenStack fournit du stockage, du réseau et du compute. Il n'en faut pas moins pour proposer aux utilisateurs un service de VDI. De plus, OpenStack propose un large choix d'hyperviseurs, dont Hyper-V, qui dans un domaine dominé par Microsoft est un avantage. D'ailleurs, Microsoft supporte les instances Windows tournant sur Hyper-V. Pour KVM, la plateforme doit être compatible avec "Windows Server Virtualization Validation Program"

La société Cloudbase.it propose des outils permettant de configurer à l'instanciation les instances Windows. L'outil Cloudbase-init permet de transformer les instances via les user-data, pour configurer par exemple l'annuaire Active Directory, les règles RDP, la configuration des applications, etc.

Pendant la session, les conférenciers ont présenté un plugin Citrix XenDesktop pour OpenStack, un plugin pour Microsoft RDS, ainsi qu'une alternative basée sur Apache Guacamole sur OpenStack.

La suite du dossier OpenStackSummit Boston :

• Jour 1
• Jour 2
• Jours 3 et 4