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 ! 17ème summit OpenStack, Osones vous fait, comme à son habitude, vivre l’OpenStack Summit de Vancouver comme si vous y étiez !

• Vers le jour 1
• Vers le jour 3
• Vers le jour 4
  

Breakout Sessions

Zuul

Avec le sortie de la version 3, et son intégration comme projet à part entière de la Fondation OpenStack, Zuul tient une place importante lors de ce Summit. Le projet avait été originellement développé comme outil d'intégration continue (CI) au sein du projet OpenStack, pour le projet OpenStack. Cette session a permis de couvrir les raisons qui ont mené à la création initiale de Zuul, ainsi que les aspects techniques de son fonctionnement.

OpenStack, c'est plus de 2000 développeurs qui collaborent lors de chaque cycle de 6 mois. Lors des périodes d'activité les plus importantes, le système d'intégration continue (CI) d'OpenStack traite jusqu'à 2000 jobs par heure, et ce sont plus de 1000 changements (commits) qui sont mergés chaque mois. Les jobs sont distribués sur des nœuds fonctionnant dans 5 clouds publics et 2 clouds privés différents.

Le projet OpenStack, dont les bases reposent sur le principe des 4 Opens (Open Source, Open Design, Open Developement, Open Community), a fait le choix de traiter ses systèmes (dont la CI) et outils (dont Zuul) de développement de la même manière que ses productions logicielles. Monty Taylor parle ainsi de :

• Fifth Open : les 4 Opens appliqués à l'infrastructure (tous les composants logiciels utilisés pour l'infrastructure de développement sont ouverts)
• Sixth Open : les 4 Opens appliqués aux opérations (les processus de déploiement sont similaires aux processus de développement, ils sont ouverts)

Zuul est donc un logiciel ouvert au même titre que le reste d'OpenStack, et permet de mettre en œuvre des processus de développement (CI) et de déploiement (CD) ouverts. Cela répond à la question fondamentale soulevée par la conférence intitulée "Free Software Needs Free Tools" également présentée aujourd'hui.

L'outil de déploiement Ansible est utilisé au cœur de Zuul. Les jobs sont écrits en langage Ansible, ce qui permet entre autres de faciliter l'utilisation de Zuul pour du déploiement continu (CD).

OpenStack-Helm - Project Update

OpenStack Helm est un ensemble de Helm Chart, pour ceux qui ne connaissent pas Helm, il s'agit d'un package manager pour Kubernetes. Helm permet de templatiser des fichiers YAML Kubernetes afin de faciliter les déploiements.

OpenStack Helm a donc pour but de fournir un ensemble de Helm Chart afin de déployer OpenStack on top de Kubernetes et ainsi profiter des fonctionnalités de self-healing de Kubernetes.

Pour Rocky le projet atteindra sa version 1.0 avec des interfaces stables et un processus de déploiement clair. Cela permettra ensuite d'ajouter sereinement des projets OpenStack annexes.

En parallèle, plusieurs projets transverses ont vu le jour :

• LOCI & Kolla : pour le packaging en images Docker des services OpenStack
• Airship

Curse your bones, Availability Zones

Commençons par quelques rappels :

• Une région est, généralement, une zone géographique distincte au sein d'un cluster OpenStack, chaque région possède ses propres services OpenStack, hormis Keystone qui est commun à toutes les régions. Elles sont visibles par les utilisateurs.
• Une AZ (Availability Zones) est visible par l'utilisateur et lui permet de choisir où schéduler ses ressources. Il n'a en revanche pas conscience de comment son "implémenter" ses AZ
• Un agrégat d'host est invisible par l'utilisateur et est généralement crée par un administrateur pour regrouper des hosts ayant des caractères spécifiques
• Un host ne peut appartenir qu'à une seule AZ mais à plusieurs agrégats.
• Par extension de la règle précédente, les AZ ne peuvent se chevaucher.
• Une seule AZ maximum peut être spécifiée dans l'instanciation d'une machine virtuelle

Le présentation se concentre exclusivement sur les AZ, sur ce qu'elles peuvent définir ainsi que sur les bonnes et mauvaises pratiques les concernant.

Une AZ représente une "single zone of failure". C'est à dire qu'une application tournant sur des instances situées toutes dans une même zone ne peut être considérée comme hautement disponible. Une AZ permet à un administrateur de signifier à ses utilisateurs, de façon macro, comment est conçu l'infrastructure sous jacente.

On peut définir une AZ selon n'importe quel critère :

• Par alimentation électrique
• Par rack
• Par salle d'un datacenter
• Par étage d'un datacenter
• Par bâtiment
• Par ce qu'on veut !

On se concentra ici uniquement sur Nova, mais les AZ sont disponibles pour d'autres services, notamment Cinder et Neutron.

Lors de la création d'une instance, l'utilisateur doit spécifier explicitement la zone de disponibilité dans laquelle il souhaite schéduler son instance. Par défaut, un choix est automatiquement fait selon la configuration de Nova. Cette décision explicite implique qu'un trop grand nombre d'AZ nuira à l'expérience utilisateur. Trop de choix empêchera de comprendre clairement le sens derrière ces AZ. A savoir qu'il n'existe pas de "tiering" concernant les AZ, c'est à dire qu'il n'existe pas de niveaux d'AZ imbriqués les uns dans les autres.

Il n'est pas toujours simple de trouver une méthode pour découper son cloud car il n'est pas toujours évident de trouver des SPOF évident.

Pour l'administrateur les AZ permettent de simplifier les maintenances et les updates/upgrades. Dans un process clairement défini, on peut s'en servir pour décider de l'organisation de ces maintenances.

Les AZ sont aussi parfois utilisées pour les usages suivants, ce sont toutes de mauvaises idées !

• AZ-vmware-1 et AZ-kvm-1

La notion "d'availabilité" est absente et ce choix d'hyperviseur devrait être géré grâce aux agrégats d'hosts associés à des flavors spécifiques

• AZ privé pour des questions de sécurité

Les AZ ne peuvent être privé et sont visibles de tous les utilisateurs et il n'est pas possible d'en restreindre l'utilisation. En revanche, des flavors privées permettent de schéduler des instances sur des noeuds dédiées, créant cette isolation qui peut parfois être nécessaire.

• Une AZ par host

Nova permet de créer des "servergroups" implémentant des fonctions d'affinité/anti-affinité permettant de placer des instances sur des hosts différents (ou les co-localiser)

En conclusion, les AZ rendent service à la fois aux administrateurs et aux utilisateurs mais nécessitent d'être correctement définies afin d'atteindre leur potentiel.

Cloud Native Infrastructure with Kubicorn and the Kubernetes cluster API

Kris Nova de Heptio nous a présenté Kubicorn un projet de déploiement d'infrastructure pour Kubernetes. Alors Kubicorn, qu'est ce que c'est ?

• Un système d'injection de commandes
• Un système de provisionning d'infrastructure Kubernetes
• Bibliothèque Go
• Outils CLI
• API driven
• Un wrapper Kubeadm
• Atomic

Petit comparatif entre Kops et Kubicorn :

Kubicorn	Kops
Construit comme une bibliothèque	CLI "first"
Construit avec Kubeadm	Construit avec Nodeup
Pas de garanti	cluster garanti
"Bring your own everything"	pas customisable par design
Reconciler pattern	terraform reconciler patterns
Utilise les Ips pour monter des noeuds	Utilise le DNS pour monter des noeuds

Alors, qu'est-ce qui différencie Kubicorn des autres produits ? C'est l'un des rares outils de déploiement qui supporte le nouveau projet du SIG(Special Interest Group)-Cluster : Cluster API

Cluster API a pour but de fournir des API unifiées, développées avec la communauté, afin de permettre à Kubernetes de gérer l'infrastructure sous-jacente et ainsi s'auto réparer et se mettre à jour par exemple.

CloudKitty : project update (Queens)

Christophe Sauthier, le CEO de la société Objectif Libre basée à Toulouse, nous propose un point d'étape sur le projet CloudKitty.

Rappelons que CloudKitty est le composant permettant de présenter des données relatives à l'utilisatiion des ressources IaaS à des fins de facturation.

Comme tous les autres composants d'OpenStack, CloudKitty propose une API Restful, un mécanisme d'authentification basé sur Keystone et des outils client-side.

Parmi les nouveautés proposées à l'occasion de la version Queens d'OpenStack, nous retiendrons :

• l'utilisation de SQLAlchemy, un ORM Python qui apporte un certain niveau d'agnostie vis-à-vis du moteur SQL utilisé pour stocker les données persistantes
• un nouveau collecteur permettant de recueillir des métriques générés par le service Monasca d'OpenStack (Monitoring as a Serviceà)
• l'abandon du collecteur Ceilometer, qui est remplacé par le collecteur Gnocchi

Concernant la release Rocky actuellement en cours de développement, les grandes lignes de la roadmap sont :

• la consolidation et le refactoring du code dans son ensemble
• l'amélioration de la scalabilité (api, stockage)
• la refonte du GUI
• une méthode de description des métriques à collecter plus efficace

Christophe Sauthier nous rappelle l'importance et la volonté de poursuivre la collaboration transversale avec les projets OpenStack OSA, Kolla et Horizon. Pour finir, il lance un appel aux contributeurs ainsi qu'aux retours d'expériences utilisateurs.

La Team Osones