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

• Jour 1
• Jour 2
• Jours 3 et 4

We are back ! Again !

Après Tokyo, Austin et Barcelone, cette nouvelle édition de l’OpenStack Summit revient à Boston, une des premières villes à accueillir le Summit - 600 personnes étaient présentes à l'époque. Cet évènement mondial s’adresse aussi bien aux techs (Architectes, Ops, développeurs) qu’aux fonctions commerciales et stratégiques des opérateurs de Cloud. Au delà d’OpenStack, ce summit abordera l’ensemble de la “stack” : Kubernetes, Docker, Ansible et Ceph seront - entre autres - de la partie.

La première Keynote

9h00 : c’est dans une salle plus petite que les précédentes éditions que commence cette première journée. La Keynote de Jonathan Bryce, Executive Director de la fondation OpenStack, ouvre le bal avec quelques chiffres issus de l'OpenStack user survey de 2017, parmi lesquels l'augmentation des déploiements de 44% par rapport à l'année précédente et la barre des 5 millions de cores en production ! Des chiffres encourageants pour un projet qui a définitivement trouvé sa place dans l'écosystème Cloud.

Jonathan Bryce a comparé les premières générations d'OpenStack avec la génération actuelle avec un focus sur :

• les objectifs : le but originel d'OpenStack était d'avoir une solution d'infrastructure hyper scalable
• l'adoption : au début OpenStack était utilisé uniquement par des sociétés axées sur la technologie et la solution qui était encore immature, nécessitait de très bonnes ressources techniques afin de l'implémenter, alors qu'aujourd'hui la technologie OpenStack a été améliorée et "simplifiée" permettant à de plus petite structure de pouvoir l'implémenter plus facilement et souvent dans le but de diminuer le cout de l'infrastructure.
• les défis : à l'origine le plus gros défis d'OpenStack était technologique (de par la grande ambition du projet) et d'arriver à fédérer des talents autour de la solution quand aujourd'hui le défis d'OpenStack réside dans les processus et la culture inhérente au Cloud Computing.

“Cost Less, Does More”

Après ce rapide retour sur les résultats de l'OpenStack User Survey, Jonathan évoque ce qui constitue selon lui l'évolution des attentes vis-à-vis du Cloud. Il n'est plus seulement question de "l'hyper scalabilité", mais également d'un ensemble de changements importants: NFV, IPv6, Cloud nationaux et/ou locaux, cloud Hybride, conteneurs, IoT, Edge Computing... Des challenges auxquels répond OpenStack et qui seront évoqués lors des prochains jours.

“Taking OpenStack Out to the Network Edges”

La Keynote continue en évoquant l' “Edge computing” - la capacité de traiter des données sans passer par des “nodes” centralisés. Beth Cohen de Verizon présente en cette occasion le fonctionnement de leur service sur OpenStack. Une fois conteneurisé, Verizon propose de l’ “OpenStack in a Box”, un boitier qui permet de décentraliser les services.

Si l'Edge Computing est pour le moment utilisé par le marché des télécoms, d'autres verticaux comme la logistique ou le retail peuvent bien entendu tirer profit de ces avancées.

“Managing Kubernetes on OpenStack at Scale”

Une autre thématique qui sera très présente ces jours ci : les conteneurs et Kubernetes. Après une introduction de AT&T qui utilise OpenStack pour leur service de vidéo à la demande “directTV”, la keynote bascule sur les conteneurs, avec Ebay qui est un des plus grand utilisateurs d’OpenStack et de Kubernetes au monde.

Les nouveautés de cette édition du Summit

Ouverture de la MarketPlace

Petit changement cette année ! Exit le fameux Booth Crawl qui conclut généralement la première journée du summit par l’ouverture de la MarketPlace (et la dégustation de quelques bières et burgers). Pour ce summit, la MarketPlace ouvre à 10H45, directement après les Keynotes. La petite soirée est bien maintenue, mais sous le nom de “MarketPlace Mixer”, nom qui met les échanges d’avantage en avant.

Le Forum

Ce summit accueillera également le “Forum”, un nouveau format de table ronde permettant de fluidifier les feedbacks et les échanges autour de thématiques spécifiques. Plus de devs sessions et d'ops sessions, mais uniquement des sessions mixant développeurs et opérateurs afin d'avancer concrètement sur les l'identification des besoins et les solutions à apporter.

Sessions du Forum

Etcd nouvelle dépendance d'OpenStack ?

Cette session concerne l'ajout d'etcd dans les dépendances générales d'OpenStack, au même titre qu'une base de données telle que MySQL et un système de passage de messages tel que RabbitMQ. Des premiers besoins sont clairement identifiés par les développeurs, et un consensus semble être atteint parmi les opérateurs.

Quelques besoins identifiés :

• Stockage de la configuration des composants OpenStack
• Distribution Lock Management
• Service liveness : gestion de l'état des services OpenStack

La question s'est posée du choix entre etcd et un autre système de stockage clé-valeur tel quel Zookeeper. Il a ainsi été envisagé d'utiliser une bibliothèque implémentant une couche d'abstraction au-dessus de plusieurs de ces solutions, comme Tooz.

Finalement, etcd semblant être la meilleure option, il a été décidé de ne pas ajouter de complexité inutile avec une couche d'abstraction et de ce concentrer sur l'utilisation de cette solution.

Aller plus loin

Un des cas d'utilisation d'etcd a été discuté dans la session évoquée ci-dessous.

Gestion de la configuration - YAML config generator

Les services OpenStack utilisent pour le moment des fichiers de configuration INI. Un des problèmes majeurs pour les opérateurs et les outils de déploiement est le maintien de ces fichiers ainsi que les options des différents services, par exemple découvrir les options de configuration par défaut ainsi que les options dépréciées entre les différentes versions. Ce problème est traité par l'ajout d'un générateur de configuration dans la bibliothèque Oslo qui permettra de découvrir et de générer un YAML avec les différentes options :

generator_options:
    args: --config-file=etc/nova/nova-config-generator.conf
    output_file: etc/nova/nova.conf.yaml
    wrap_width: 80
    namespace:
        - nova.conf
        - oslo.log
        ...
    summarize: False
    # minimal intentionally omitted as I don't think it makes sense in
    # this context
    [more generator details can be added as desired]
options:
    DEFAULT:
        image_service:
            # The list of parameters is for example only.  The actual output
            # can include anything deployment tools would find useful.
            default: nova.image.glance.GlanceImageService
            documentation: Service used to search for and retrieve images.
            type: string
            required: True
            deprecated: False
            deprecated_reason: blabla
            deprecated_for_removal: False
            deprecated_since: XXX
            deprecated_name: old_parameter
            [all other parameters passed to the opt constructor]
        new_opt:
            deprecated_name: old_opt
            ...

Lire la spécification

Backend de stockage pour la configuration

Pour le moment les fichiers de configuration sont stockés dans des fichiers INI. Dans le futur, des backends seront ajoutés à oslo.config permettant par exemple de stocker la configuration :

• Dans des fichiers YAML
• Dans un K/V tel que etcd
• Dans des fichiers INI qui pourraient être un jour dépréciés

Ces changement seront transparents pour les services puisque oslo.config fournira l'abstraction nécessaire à l'obtention des options de configuration.

Aller plus loin

Quotas dans un contexte hiérarchique

Sujet Keystone et complexe s'il en est.

Une spécification existant déjà depuis quelques temps considère l'intégration de la fonctionnalité des quotas directement au sein de Keystone au lieu d'en laisser la charge à chacun des projets. On peut en attendre une expérience utilisateur nettement plus homogène et donc améliorée.

Le sujet principale de la session du jour concernait l'extension de cette spécification au projets hiérarchiques. Autrement dit, comment traiter des quotas définis sur un projet et sur un sous projet ? Beaucoup de cas à considérer ! Et donc un sujet loin d'être entièrement traité.

Dépréciation du back-end PostgreSQL

Une session a été consacrée à la proposition de déprécier PostgreSQL. MySQL resterait alors le seul back-end de base de données supporté par OpenStack pour des environnement de production. C'est d'ailleurs déjà la solution utilisée par une écrasante majorité des déploiements. Néanmoins des inquiétudes de certains utilisateurs n'ont pas permis de valider une telle décision pour l'instant.

Aller plus loin

Fin de Stackalytics ?

Stackalytics, l'outil utilisé par la communauté pour visualiser les métriques de contribution à OpenStack, pose aujourd'hui nombre de questions. En effet, les métriques brutes prises telles quelles ne sont pas pertinentes dans de nombreux cas ce qui provoque quelques effets pervers. Par ailleurs, l'outil n'est plus activement maintenu et ainsi certains bugs contribuent à rendre son utilisation problématique. Il est par conséquent envisagé d'abandonner Stackalytics, néanmoins cette session a montré que la communauté n'était certainement pas prête à s'en passer complètement. Ce sujet étant en plus traité avec une priorité faible par les développeurs (ce qui se comprend aisément), il est à parier que la discussion se prolonge encore pendant quelques temps.

Zun Onboarding

Zun est un projet de conteneurs as a service basé sur les composants d'OpenStack. De la même façon que nova-docker ou nova-lxd, Zun permet de contrôler simplement le daemon Docker d'un nœud compute. Pour l'instant, les fonctionnalités sont limitées et reprennent celles de Docker :

• Run un conteneur
• Se connecter à un conteneur
• Détruire un conteneur

Dans Zun, pas de fonctionnalités d'orchestration avancées comme sur Kubernetes ou Swarm, l'intérêt est pour le moment de proposer un simple scheduler pour lancer des conteneurs. Dans un futur proche, Zun utilisera le scheduler de Nova ainsi que l'API placement qui utilise les Cellsv2.

Zun peut être très utilise pour rapidement tester des conteneurs sans besoin de scheduling avancé. Zun souhaite à l'avenir s'intégrer avec différents COE (container orchestration engine) tout en fournissant une API unifiée pour lancer des tâches sur différents COE. Attention cependant à ne pas refaire les erreurs de Magnum au début du projet. Une partie de la team Zun est issue de la team Magnum. Au départ, Magnum s'est lancé dans une réécriture des APIs des différents COE, ce qui à rendu l'API trop complexe à maintenir sur le long terme. C'est pour cela que Magnum à fini par se concentrer sur les COE pour ensuite les piloter via l'API native du COE. Si Zun souhaite prendre cette directions, ils risquent de se heurter aux même problématiques.

Les conférences

OpenStack and OVN : What's New with OVS 2.7

Le projet OVN est parti from scratch après le retour d’expérience de OVS notamment. Il est développé par l’équipe qui s’occupe de OVS, sous l'égide de la fondation Linux Foundation Projects. C’est une solution complète qui se veut utilisable aussi bien par OpenStack (avec l’agent ML2) qu’avec Kubernetes, Mesos ou oVirt.

Actuellement déployable depuis Devstack ou Tripleo, il existe aussi des playbooks Ansible pour migrer depuis un OpenStack en ML2 OVS.

La grosse différence avec OVS est son architecture plus proche des solutions SDN classiques. OVN n'utilise pas de namespace. Il dispose d'un contrôleur avec une BDD partagée (bientôt distribuée dans les prochaines releases (une release/6 mois)). Cette architecture permet au paquet d'être traité plus rapidement, le trajet du paquet est calculé en entrée par OVN, il est ensuite routé à destination par un routeur distribué. OVN ne gère pas encore le multicast.

En pratique cela donne un gros gain de performance (de l'ordre de 70%) sur la création d'une VM car aucune action n'est à faire. En effet, il suffit de créé une entrée dans la BDD du contrôleur OVN, il n'y a pas de namespace à créer ou d'iptables à changer.

Le projet OVN demande de nouveaux agents neutron pour les fonctions NFV (LB, VPN...), les agents actuels ne sont plus utilisables.

When One Cloud is Not Enough: An Overview of Sites, Regions, Edges, Distributed Clouds, and More

Il s'agit d'une conférence qui récapitule les méthodes qui existent pour construire un cloud réparti sur plusieurs datacenters.

La première est simplement de mettre les composants principaux d'OpenStack sur un DC et des computes sur d'autres DC. On sépare ensuite la gestion de ces computes à l'aide d'agrégats et d'AZ. Cette solution a l'unique avantage de repartir la charge des instances mais aucune HA est possible, ni sur le control plane ou sur la connectivité des instances.

Puis nous avons les nova cell. Ils agissent uniquement au niveau du composant nova. Concrètement, les services autres que nova-api peuvent être groupés dans une cell qui dispose de sa propre base de données et d'une file de message dédiée. Cette solution a fait ses preuves notamment sur le cloud du CNRS.

Ensuite, nous arrivons aux régions qui vont encore plus loin dans la séparation. Dans une architecture avec régions, seul le composant d'authentification est partagé. Chacune de ces régions dispose de ses endpoints. Donc chaque région a ses propres services. Les défauts sont que les flavors, les quotas ne sont pas partagés. Pour les partager, il existe un projet appelé KingBird. Tout est séparé sauf l'authentification. Dans une architecture avec régions, Keystone peut être installé sur un seul DC ou il peut être partagé avec sa BDD de façon synchrone ou pas.

Ensuite, nous avons la fédération. Le Keystone d'un premier OpenStack sert d'identité provider à un second cloud OpenStack.

Et enfin, on arrive au projet de Tricircle. Il s'agit d'un outil d'automatisation qui permet de déployer des networks et des routeurs dans plus d'une région.

Kubernetes on OpenStack : table ronde

Cette conférence prenait la forme d'une table rond où 4 personnes avec notamment Adrian Otto, actuel PTL de Magnum. Des ingénieurs de CoreOS, Comcast et Platform9 étaient aussi présents. Adrian Otto est revenu sur les raisons qui font de Kubernetes le nouveau hottest buzz word depuis OpenStack. Complété par Tony Campbell de CoreOS, ils ont mis en avant la simplicité de Kubernetes, son très faible besoin de hack pour le faire fonctionner et la puissance de sa communauté. La discussion s'est rapidement orientée vers "pourquoi OpenStack est un bon complément à Kubernetes". La réponse étant que Kubernetes ne correspond qu'à une seule couche d'un cloud complet. Si on essaye de faire tourner Kubernetes sur du baremetal, beaucoup de fonctionnalités de fonctionneront pas "out of the box", on pense notamment au persistent storage, aux services de type load balancer ou à la scalabilité verticale. Néanmoins, cloud ne rime pas nécessairement avec machines virtuelles, l'idée étant de disposer d'un IaaS afin de tirer le maximum des API disponibles. Celles ci pourraient tout à fait permettre de déployer Kubernetes sur des hosts Ironic par exemple. D'autres services "application aware" comme fluentd ou traefik par exemple viennent compléter ce "cloud complet".

Voir les offres de formations Docker/Kubernetes d'Osones Besoin d'accompagnement sur vos infrastructure de conteneurs ?

Présentation de 10 solutions de SDN dans une présentation éclaire de 10 minutes

Carlos Rivera, ingénieur cloud chez CloudOps, a présenté rapidement 10 solutions de SDN. Il a commencé son talk en rappelant ce qu'est le SDN : une solution permettant de piloter son réseau (hardware ou software) grâce à des APIs. Il a bien sûr parlé de Neutron, la solution SDN d'OpenStack. Ce qui a amené la question suivante : pourquoi a t-on besoin d'une solution de SDN séparée d'OpenStack ? Implémenter une autre solution de SDN permet par exemple :

• de pouvoir connecter plusieurs techonogies (VM, conteneurs, baremetal)
• avoir une solution SDN qui n'est pas uniquement utilisable dans la plate-forme cloud mais également pour d'autres services IT
• avoir de meilleures performances
• être libre de son choix de SDN

Il a ensuite brièvement introduit plusieurs solutions SDN :

• Dragon Flow : un projet OpenStack apportant un contrôleur SDN distribué pour Neutron
• OpenDayLight : idéal d'après Carlos pour orchestrer des réseaux physiques ou virtuels
• Contrail : fortement automatisé, compatible avec OpenStack, VMware et k8s
• Calico
• Big Switch : compatible avec ESXi, Hyper-V, KVM, XEN. Décharge Neutron de la gestion des réseaux de niveaux 2 et 3.
• Nuage Network : une des solutions mise en avant par Carlos expliquant que c'est une des solutions les plus complètes.
• VMware NSX et NSX-t.
• Cisco VTS et ACI.

Heat : project update

Rico Lin (EasyStack) et Zane Bitter (Red Hat), deux développeurs du projet Heat, nous offrent un "update" du projet qui incube le composant d'orchestration de ressources d'OpenStack, Heat. Rappelons que Heat permet de créer, mettre à jour et maintenir facilement, grâce à des templates au format YAML, les ressources qui composent les infrastructures virtuelles sur lesquelles s'appuient les applications.

De la release Newton au premier jalon de la release Pike (Pike-1) - la release actuellement en cours de développement - 18 nouveaux types de ressources ont fait leur apparition dans Heat. Ces nouveaux types de ressources appartiennent aux composants monasca, zaqar, sahara et magnum.

La commande "$ openstack orchestration resource type" permet d'obtenir la liste des types supportés par le service Heat courant.

Rico et Zane nous énumèrent ensuite quelques éléments de la roadmap court terme de Heat, en fait celle de la release Pike :

• support de la version 3.5 du langage python
• support de nouvelles ressources neutron : "segment" et "vlan trunk port"
• améliorations techniques : architecture interne simplifiée, consommation mémoire réduite, fiabilité des grandes stacks meilleure
• deux nouvelles fonctions intrinsèques : make_url et list_concat_unique

Disons maintenant quelques mots sur ce que les développeurs de Heat nomment "auto-healing", souvent mieux connu sous le terme un peu réducteur de "auto-scaling". En fait, il s'agit de la capacité d'une infrastructure contrôlée par Heat à s'auto-réparer ou s'auto-adapter. Un cas simple est la réinstanciation automatique d'un serveur virtuel tombé brutalement en panne, ceci afin de rester au-dessus du seuil minimal fixé. Ceci peut-être obtenu en combinant avec Heat les services compute (nova), telemetry (ceilometer), messaging (zaqar) et tasks workflow (mistral). Un exemple de template Heat pour mettre en œuvre l'auto-healing est disponible ici : https://git.openstack.org/cgit/openstack/heat-templates/tree/hot/autohealing

Enfin, et c'est habituel et naturel dans la communauté OpenStack, Rico et Zane lancent un appel à contributions et nous rappellent l'importance des blueprints, des remontées de bugs, des soumissions de patches et des revues de spécifications pour obtenir un service Heat performant et adapté aux besoins.

Notons pour finir que la page wiki du projet Heat est ici https://wiki.openstack.org/wiki/Heat et que le meeting hebdomadaire se tient sur le canal #openstack-meeting-5, chaque mercredi, à 15h00 UTC.

Un petit tour par les stands : quelles solutions pour la métrologie/supervision ?

Aujourd'hui je me suis fixé un objectif : faire le tour des solutions de métrologie/supervision présentes sur le salon. Pourquoi ? Parce que lorsque Osones préconise une solution de déploiement OpenStack à ses clients, le sujet de la métrologie / supervision est toujours délicat :

• Il n'y aucun système de métrologie/supervision natif mutli-vendor dans le projet OpenStack,
• La plupart des solutions de métrologie/supervision ne sont pas compatibles avec les serveurs de type "cattle", et n'ont pas forcément de sondes pour les différents services OpenStack,
• Les distributions supportées OpenStack de type Helion ou Mirantis embarquent des solutions souvent "single-vendor" et spécifiques à la distribution.

Il nous faut donc trouver une solution facile à installer (comme une appliance), qui surveille à la fois l'infra OpenStack et les ressources lancées, tout cela "On Premise" car les clients de cloud privés sont généralement réfractaires à l'envoi de métriques sur internet.

Dynatrace

Dynatrace est un outil de supervision très pertinent pour superviser un cluster OpenStack, ainsi que les instances. Cet outil est multicloud et permet de gérer des instances d'autres cloud d'infrastructure comme AWS. Un travail conséquent a été réalisé pour intégrer la technologie OpenStack. Dynatrace "connait" les services OpenStack. Malheureusement, cet outil n'existe qu'en SaaS. Les équipes sont capables de l'installer sur site, mais ce n'est clairement pas un processus maitrisé. N'existant pas "on premise", c'est un NOGO pour nos clients.

Zabbix

Osones utilise Zabbix pour ses clients infogérés AWS, mais pas encore pour ses clients OpenStack. Bien qu'il soit très performant, il nécessite un bon niveau de maitrise pour pouvoir l'exploiter dans un environnement cloud. Zabbix ne dispose pas de module OpenStack. La configuration est à la charge des utilisateurs. D'ailleurs, la société Zabbix ne communique pas sur les clients qui utilisent leur technologie sur une infrastructure OpenStack. Les ingénieurs présents sur le stand m'ont assuré qu'ils avaient de très bons retours sur OpenStack, mais la configuration étant à la charge des clients, Zabbix ne souhaite pas communiquer dessus...pour le moment.

Nativement Zabbix ne connait pas OpenStack, c'est donc un NOGO pour nos clients.

Groundwork

Comment dire... Lorsque vous venez à un salon, vous vous attendez à ce que les exposants... exposent ! Avec un gros "Monitoring" affiché sur le stand, je m'attendais à une démonstration intéressante. Groundwork était uniquement présent pour distribuer un tract, tout en demandant aux visiteurs de prendre rendez-vous pour une démonstration la semaine suivante.

Datadog

Datadog est un outil aussi puissant que cher. Bien que l'outil connaisse parfaitement les différents modules OpenStack, il n'existe pour le moment qu'en version SaaS. C'est donc un NOGO aussi pour ce dernier.

La solution semble ne pas être à l'OpenStack Summit de Boston !

La suite du dossier OpenStackSummit Boston :

• Jour 1
• Jour 2
• Jours 3 et 4