Après Vancouver, Tokyo, Austin et Barcelone, Boston, c’est au tour de Sydney d’être la ville de l’OpenStack Summit ! 16ème summit OpenStack, Osones vous fait, comme a son habitude, vivre l’OpenStack Summit de Sydney comme si vous y étiez !

Le menu est simple : par ici pour le JOUR 1 et le jour 3 !

Cette deuxième journée est marquée d'un évènement national Australien : la Melbourne Cup, une course hippique qui se déroule le premier mardi de novembre à Melbourne. C'est la principale compétition hippique d'Australie dont la première édition s'est tenue en 1861.

C'est donc tout naturellement qu'une pose a été organisée pendant cette deuxième journée de conférences pour nous permettre de vivre ce moment, et la magnifique victoire de Rekindling.

COREY BROWN, YOU STAR
How good was the run from Rekindling? Did you back it?https://t.co/Z8yplyfw0t pic.twitter.com/B2pqIi7vvE

— Superracing (@superracing) 7 novembre 2017

Il est aussi agréable en cette deuxième journée de voir que le soleil est enfin au rendez-vous !

#OpenStackSummit #WeAreOpenstack #teamOsones #australia #Red&Black #frenchies #sydney

A post shared by Osones (@livinthecloud) on Nov 6, 2017 at 9:45pm PST

Sans plus d'introduction, plongeons ensemble dans la séléction Osones de ce qu'il fallait retenir en cette deuxième journée de summit !

Le coeur du sujet : les Breakout sessions retenues par Osones !

- How to survive hybrid cloud on OpenStack and AWS

Cette conférence est présentée par ProSiebenSat.1 Media SE, une société allemande utilisant à la fois un cloud OpenStack privé ainsi que du cloud public AWS (Région Francfort).

Le cloud hybride est une arlésienne depuis un certain temps dans la communauté cloud, tout le monde souhaite en faire mais peu ont réussi à réellement faire fonctionner des applications déployées sur une infrastructure cloud hybride. Le challenge est encore plus grand lorsque les deux clouds proviennent de technologies différentes comme OpenStack et AWS.

Les intérêts pour ce genre de combinaisons sont nombreux :

• la résilience
• la scalabilité
• les économies financières
• pas de vendor lock-in (indépendance vis à vis d'un provider)
• infrastructure as code

L'exemple donné par la présentation se place dans une situation avantageuse du fait que le cloud privé et le cloud public se trouvent dans la même région géographique, permettant d'atteindre des latences faibles (1,5ms de latence entre une instance du cloud OpenStack et une du cloud AWS), condition indispensable à la réussite d'un cloud hybride.

Contrairement à la plupart des clouds hybrides où l'idée de base est de pouvoir effectuer du burst sur un cloud public et garder la majorité des workloads sur le cloud privé, la présentation implémente plutôt le concept de plan de continuité d'activité. Bien entendu, la fonction classique de bursting est présente.

Grâce à la fonction Direct Connect d'AWS, les deux datacenters sont directement connectés via un lien privé. Un load-balancer est présent sur chaque cloud et chaque workload deployé est présent dans sa configuration minimale sur chaque cloud. Cela permet en pratique d'obtenir un PCA en cas de perte complète d'un des deux clouds. Cela permet également de ne pas impacter la disponibilité des applications lors d'opération impactant la disponibilité des services OpenStack. La scalabilité d'une application peut être effectuée sur l'un des deux clouds en fonction des performances nécessaires, des coûts ou d'autres métriques.

Depuis septembre 2017, les Network Load Balancer (NLB) peuvent cibler des IP en dehors d'AWS et donc load balancer le trafic à la fois sur des instances AWS et OpenStack. Sur OpenStack cette fonction est déjà présente depuis quelques temps. Néanmoins les NLB ne supportent pas l'offloading TLS, ce qui peut limiter son utilisation à un load balancing interne ou alors prévoir de faire porter les certificats x509 directement sur les frontaux web.

Voir les articles Osones sur les Network Load Balancer :

• (https://blog.osones.com/cetait-cette-semaine-sur-aws-lundi-11-septembre-2017.html)
• (https://blog.osones.com/cetait-cette-semaine-sur-aws-lundi-25-septembre-2017.html)

L'utilisation de Route53 permet de bénficier des fonctions de health check et donc d'enregistrer deux IP par RR (une pour chaque cloud) et dans le cas où un des clouds serait tombé, il disparaitait automatiquement et le trafic continuerait d'être acheminé.

Les limitations sont en revanche assez nombreuses. De façon à avoir un cloud hybride homogène, les fonctions fournies par les deux clouds doivent être très similaires ou bien accepter que certains workflows ne pourront être déployés que sur un des deux clouds du fait de l'utilisation d'une fonction non présente sur le deuxième. L'évolution extrêmement rapide des fonctionnalités AWS imposent un suivi régulier qui peut être chronophage (les WIR Osones sont là pour ça ! ). Et enfin, l'utilisation intensive d'outil de configuration est bien entendu obligatoire. Cela ne consiste pas en un frein étant donné qu'il s'agit généralement d'un prérequis à la bonne santé de n'importe quel cloud.

- Point certifications sur OpenStack : "Certified OpenStack Administrator"

La COA (Certified OpenStack Administrator), est l'unique certification délivrée par la Fondation OpenStack. Cette certification se base sur la version VANILLA d'OpenStack ce qui la rend neutre vis à vis des différents éditeurs. Lancée depuis 2016, elle a été passée plus de 2000 fois avec un taux de réussite de 60%.

Cet examen est un test technique (travaux pratiques) et non pas un QCM. Lors de cette certification vous aurez accès à un OpenStack en version Newton sur lequel vous serez testés sur 32 tâches basiques à réaliser (création d'utilisateurs et de projets dans des domaines spécifiques, création de conteneurs swift et association de droit sur ceux-ci ...).

La certification reprend les concepts basiques d'OpenStack qui vous permet de passer facilement cette certification même si vous utilisez une version différente de Newton.

De plus la certification à recemment été améliorée : - simplification de l'anglais - accès simplifié à la documentation sur un deuxième onglets du navigateur web (faut il encore selectionner la documentation de la bonne version d'OpenStack) - simplifaction de d'accès au source (openrc folder dans le home, template heat dans home ...) - la possibilité de changer de question et de revenir sur des questions précedentes plus facilement

A noter que 5 des experts Osones sont certifiés COA !

- Fondation OpenStack, CNCF et SIG

- Deux gouvernances distinctes

Depuis le lancement de Docker, l'engouement pour les conteneurs ne cesse de croître, durant ces dernières années, beaucoup de logiciels Open Source que l'on qualifie de "Cloud Native" ont vu le jour et de nombreux efforts sont réalisés afin de standardiser ces technologies, notamment grâce à la création de la Cloud Native Computing Foundation, sous la gouvernance de la fondation Linux. Son but est de faciliter l'adoption des technologies Cloud Native en supportant différents projets qui correspondent aux caractéristiques requises. Parmi ces projets, on retrouve par exemple Kubernetes, Prometheus ou encore Containerd. OpenStack existe depuis un peu plus de 7 ans et évolue à part sous la gouvernance de la fondation OpenStack.

À moins de vivre en 2014, vous avez forcement entendu parler de Kubernetes, c'est l'un des sujets omniprésents des précédents summits OpenStack et bien évidemment de celui de Sydney. Kubernetes est un projet Open Source avec un traction similaire à celle des débuts d'OpenStack : communauté en plein essor, contributeurs diversifiés, etc. On retrouve beaucoup de talks à propos de Kubernetes sur OpenStack ou OpenStack dans Kubernetes.

Les deux projets sont donc amenés à collaborer ensemble dans le cadre de divers projets : - Kolla-Kubernetes (OpenStack on Kubernetes) - OpenStack-Helm (OpenStack on Kubernetes) - Magnum (Kubernetes on OpenStack) Cependant les deux projets évoluent sous une gouvernance différente (OpenStack vs CNCF) et un des sujets de discussion du forum était justement de faciliter la collaboration entre les deux.

- Les SIG : Special Interest Groups

Dans l'écosystème Kubernetes, chaque SIG est responsable d'un domaine particulier, par exemple le SIG-cluster est responsable des sujets concernant la partie cycle de vie d'un cluster et il existe un SIG-OpenStack qui est responsable des sujet autour d'OpenStack et Kubernetes.

Un des objectifs de Queens est d'importer cette notions de SIG au sein de la communauté OpenStack et de collaborer plus efficacement avec la CNCF, notamment en termes de tests. Par exemple, les tests end to end de Kubernetes sont réalisés sur AWS, GCP et Azure et le seront prochainement sur des Clouds OpenStack.

- OpenStack Cloud provider

Kubernetes s'intègre avec différents Cloud Provider (AWS, GCP, OpenStack etc), les packages sont disponibles ici et nous avons déjà parlé un petit peu du sujet dans notre article d'hier. Une des difficultés est l'hétérogénéité des différents Clouds OpenStack en termes de configuration ou version des différents composants par exemple.

Kubernetes se repose également sur la bibliothèque Gophercloud : un SDK pour OpenStack en Go. Les SIG auront également pour taches de maintenir ces deux composants ainsi que de remonter les différents problèmes liés à l'intégration de Kubernetes et OpenStack. Le but étant de fournir une intégration plus poussée, suivie et testée.

- Aller plus loin

Les pads liés à ces discussions :

• https://etherpad.openstack.org/p/SYD-openstack-sig-k8s-collaborations
• https://etherpad.openstack.org/p/queens-ptg-sig-k8s

- Metadata, "Oh my"

Cette conférence présentée par Michael Still, développeur Nova, revient sur les fameuses metadata des instances fournies par le service de Compute de Nova. C'est l'occasion de quelques éclaircissements sur le sujet.

Il faut premièrement faire la distinction entre les metadata des user data des vendor data. Rien que ça !

Les metadata, ce sont les informations relatives à l'instance telles que : adresse IP, clé publique SSH ou encore son nom. Elles sont donc définies par Nova et ne sont pas modifiables par l'utilisateur. Les user data elles sont entièrement définies par l'utilisateur (il s'agit d'un champ libre). Enfin les vendor data sont définies par le fournisseur du cloud. Cela peut permettre de transmettre automatiquement aux informations liées à l'environnement, comme par exemple l'adresse d'un serveur NTP à utiliser.

Toutes ces data sont exposées au travers de deux mécanismes et de deux formats.

Les deux mécanismes sont :

• HTTP : accessible à l'adresse http://169.254.169.254 depuis l'instance, permet de facilement modifier les informations après le démarrage de l'instance, quelques problèmatiques de sécurité liées à l'identification
• Config drive : disque connecté à l'instance contenant les informations, ne permet pas les modifications a posteriori, mais évite l'utilisation du réseau

Les deux formats sont :

• EC2 : défini par Amazon, exposé par défaut avec le mécanisme HTTP pour assurer une compatibilité avec l'enviornnement Amazon EC2
• OpenStack : défini par OpenStack

Cloud-init supporte tous ces mécanismes et formats, et suivant sa configuration privilégie l'un ou l'autre.

- Docs/i18n - Project Onboarding

Petr Kovar et Alex Eng, Red hat Petr (PTL Docs) et Alex (équipe Zanata) sont venus nous parler des changements dans l'équipe Documentation et nous donner quelques informations sur la plate-forme de [traduction OpenStack] (https://translate.openstack.org) motorisée par le logiciel Zanata.

Depuis le cycle de release Pike, la vocation de l'équipe Documentation n'est plus tant de produire des guides et des manuels que d'apporter du support et des outils aux autres équipes projets. Le but avoué de cette ré-orientation est d'améliorer la pertinence et la qualité de la documentation produite d'une manière générale. Dorénavant, il n'est plus nécessaire de faire partie de l'équipe Docs pour produire de la documentation, chaque projet récupérant la maîtrise de la production de sa propre documentation. On voit donc que l'équipe Docs passe d'un métier de producteur à un métier de support transverse.

Concernant la plate-forme de traduction, rappelons qu'elle est actuellement animée par la version 3.9.6 du logiciel Zanata. Zanata est un logiciel Open Source de traduction collaborative, supportée par la société Red Hat, depuis Brisbane (Australie). Un upgrade de la plate-forme vers Zanata 4.0 est prévu début 2018. C'est l'équipe "Infra" d'OpenStack, en charge de l'exploitation de la plate-forme de traduction au quotidien, qui réalisera l'opération.

Deux mots sur le fonctionnement de la plate-forme de traduction : chaque jour, les chaînes de caractères pouvant être potentiellement traduites sont automatiquement introduites dans la plate-forme et mises ainsi à la disposition des traducteurs des différents pays. En retour, les chaînes de caractères une fois traduites sont automatiquement injectées dans le système d'intégragtion continue (CI) d'OpenStack et visibles par l'utilisateur final dans le dashboard Horizon, par exemple.

Pour ceux qui souhaitent contribuer de façon effective à OpenStack mais qui ne savent pas comment s'y prendre, un coup d'oeil au guide du contributeur est une bonne entrée en matière : https://docs.openstack.org/doc-contrib-guide

Et pour entrer en contact avec les membres de l'équipe Docs via irc : #openstack-docs @ Freenode

Quelques exemples de documentations disponibles sur le site de la fondation :

• concernant la release en cours de développement (Queens)
• concernant la dernière release stable (Pike)

Forum

- Neutron: Project Update

Présenté par Miguel Lavalle (PTL de Neutron sur Queens) et Armando Migliaccio (Suse, PTL de Neutron sur Mitaka, Newton et Ocata), ce Project Update a été l'occasion de faire un point sur l'évolution de Neutron dans Pike, ainsi que les objectifs en termes d'améliorations et de fonctionnalités dans Queens et Rocky, les deux futures releases d'OpenStack. Pour rappel Neutron est le projet Networking d'OpenStack depuis la release Diablo. Auparavant les fonctions réseau étaient intégrées à Nova. Neutron représente le travail de plus de 1300 contributeurs au total dont 200 pour la version Pike. Il est devenu aujourd'hui un composant OpenStack incontournable avec un taux d'adoption de 95% selon le dernier user survey de 2017.

- Fonctionalités dans Pike

Les améliorations et nouveautés dans Pike concernent la partie opérationnelle, la QoS et l'implémentation de la couche 3.Côté opérationnel, on note entre autres la possibilité de faire une upgrade de release (Ocata vers Pike) sans interruption de service, la définition d'une MTU commune par projet et un élargissement du tagging à de plus nombreuses ressources. Côté QoS, des limites de bande passante plus fines peuvent être définies (différentes entre l'upstream et le downstream si besoin) et des profils bidirectionnels peuvent être appliqués lors de l'utilisation des drivers OVS et Linux Bridge. L'API a également été réécrite. Enfin pour ce qui concerne la couche 3, les déploiements se basant sur DVR peuvent maintenant utiliser des configurations VRRP en mode actif/actif. Par ailleurs, un nouveau modèle de déploiement DVR est proposé, basé sur des IP flottantes centralisées (via DNAT) et un trafic Est-Ouest distribué.

Des améliorations sont apportés également sur la partie Stadium, le regroupement des projets qui gravitent autour de Neutron. On note par exemple l'arrivée d'un client natif pour Bagpipe, le support des os-vif sur Midonet, un DHCP natif dans OpenDaylight et le support des connexions SSL entre OVN et sa base de donnée.

- Futures releases d'OpenStack

Dans le lot de nouveautés prévues pour Queens, on note :

• la compatibilité avec Python 3
• une amélioration de la surface de couverture des tests
• l'adoption de la neutron-lib- la possibilité de faire du binding de ports multiple
• l'ajout de politiques de QoS sur les IP flottantes
• le support du QinQ
• les logs sur les Security Groups

Les développeurs anticipent déjà la version suivante d'OpenStack, Rocky, et comptent s'axer sur :

• les garanties de QoS dans l'API Nova Placement
• Migration des firewalls IPTables / OVS

C'est tout pour ce deuxième jour ! La suite du programme est avancée : par ici pour le JOUR 1 et le jour 3 !

** La Team Osones**