Osones vous propose de vivre le Summit OpenStack 2016 d'Austin, Texas !

We are back !

C'est ici que tout a commencé, à Austin au Texas, et c'est ici que nous nous retrouvons pour ce treizième summit. De retour de Tokyo, c'est parti pour Austin ! Au programme : célébration de la sortie récente de Mitaka, des dizaines de conférences, les sessions ops et surtout les sessions de préparation pour la prochaine version, Newton.

Osones est présent toute la semaine pour suivre et participer à cette semaine majeure dans l'écosystème OpenStack. Au sommaire :

OpenStack Summit - Jour 1 :

Ops Session

• Les méthodes de déploiement
• OpenStack Application Working Group

Conférences

• 1 an de big tent
• Walmart OneOps
• DEFCON 3: OpenStack Meets the Information Security Department
• Comment devenir un contributeur OpenStack - Advanced
• Comment migrer rapidement et efficacement les legacy workloads dans le cloud -par Red Hat-
• Maintenance des branches stables d'OpenStack
• Orchestration
• Upgrader OpenStack en sautant une release (Suse)

Petit tour d'horizon du "Booth Crawl"

OpenStack Summit - Jour 2 :

Keynotes

Design Summit

• Ambassadors Community Report

Les conférences

• Nathan Reller - I'm having an OpenStack Party, and it's BYOK
• Comment contribuer à OpenStack lorsque l'on n'est ni un développeur, ni très bon en anglais
• Designing for High Performance Ceph at Scale / Comcast
• Docker et Cinder
• OpenStack on top of Docker
• Pets vs Cattle, quid des données ?
• Facturation des utilisateurs d'un cloud OpenStack
• Les Tenants des clouds OpenStack : quels besoins en perspective ?

OpenStack Summit - Jour 3 :

Active User Contributor (AUC): Le statut tant attendu des Ops ?

Design Summit

• Visibilité des images dans Glance

Conférences

• Faciliter les tests des nouvelles versions d'OpenStack : déploiement sous forme de micro services conteneurisés
• OpenStack a 6 ans, l'âge de raison ?
• Tenant networks vs provider networks
• Orchestrating Cross-cloud Applications with Murano
• Overcoming Challenges in Promoting OpenStack Within Your Organization

OpenStack Summit - Jour 4 :

Design sessions

• Working group des ambassadeurs

Conférences

• OpenStack Elastic Load Balancing : passer à la vitesse supérieure avec Neutron LBaaS V2.0 et Octavia - IBM, HPE, Bluebox
• Neutron DVR : haute disponibilité du SNAT
• Neutron LBaaS v2 : Nouveautés et intégration avec Heat
• Le projet Calico

OpenStack Summit - Jour 5 :

Clôture du Summit

Rendez-vous à Barcelone!

Jour 1 : Keynotes

Cette première journée n'a pas dérogé des précédentes ouvertures de Summit : Jonathan Bryce, directeur exécutif de la fondation a ouvert cette première Keynote en annonçant la présence de 7500 personnes à Austin, 100 fois plus qu'il y a 6 ans ici même. Cela fait d'Austin le plus gros summit jamais organisé par la fondation. Il a aussi été question du dernier sondage réalisé auprès des utilisateurs (User Survey) : on y apprend que la moitié des entreprises du Fortune 100 utilisent OpenStack. Par ailleurs, le nombre de déploiements en production continuent de progresser jusqu'à atteindre 65% aujourd'hui.

L'annonce principale à retenir : * Les prochains summits (après Barcelone en octobre prochain) auront lieu successivement à Boston et à Sydney. Boston accueillera donc une nouvelle fois un Summit, 5 ans après le précédent alors que l'Australie sera pays hôte pour la première fois.

Les sponsors se sont ensuite succédés pour présenter leurs travaux autour d'OpenStack, alternant choix technologique et choix stratégique.

AT&T était un des premiers sponsors à présenter ses travaux. L'un des plus gros telcos au monde montrait que l'explosion des communications mobiles et de la consommation de données des 10 dernières années avaient rendu l'utilisation d'une infrastructure cloud primordiale. L'utilisation de commodity hardware et de VNF (Virtual Network Functions) ainsi qu'une volonté d'échapper au vendor lock-in ont permis une réduction des coûts, ont apporté de l'agilité et de la vitesse dans le déploiement d'infrastructure et services réseaux.

AT&T sont par ailleurs les heureux gagnants du Superuser Award.

Boris Renski, membre du board OpenStack et co-fondateur de Mirantis est ensuite monté sur scène accompagné de son ours (parce que c'est normal en Russie). Son exposé non technique visait à comprendre les échecs des déploiements OpenStack. Le point principal étant que 9 fois sur 10, le problème ne vient pas de la technologie mais des changements apportés aux process et aux équipes techniques. La transformation numérique est un tout, l'évolution des technologies ne peut pas à elle seule être une solution, c'est tout un écosystème qui doit changer pour que cette transformation soit une réussite.

Ops Session

Ce lundi était consacré, côté design summit, à l'Ops summit, c'est-à-dire des sessions de discussion/travail pour les Ops.

Les méthodes de déploiement

Un après-midi orienté déploiements et notamment la question qui divise, conteneurs ou pas conteneurs. Le gros problème actuel est la dependencies hell entre les différents projets OpenStack. Dans un monde parfait où les montées de version ne provoquent pas de régression, le débat n'aurait pas lieu d'être. Mais ce n'est malheureusement pas le cas. Entre les paquet maintenus par la distribution, déployés depuis les sources et/ou l'utilisation de virtualenvs pour éviter les conflits avec pip, il n'existe pas de solution de déploiement parfaite et c’était le sujet de discussion de cet après-midi.

Si l'on met de côté les distributions OpenStack (Helion, RDO, MOS, etc.) il existe une multitude d'outils / technologies de déploiement :

• OSA (OpenStack Ansible) : ensemble de playbooks Ansible + LXC pour les services OpenStack
• Kolla : Docker pour les services OpenStack + Ansible
• Distribution classique : avec outils de gestion de conf (Ansible, Puppet, Chef,etc.)

Les conteneurs créent cependant de nouvelles problématiques, telles que l'orchestration entre les services OpenStack et la configuration des conteneurs eux mêmes. Et finalement peu importe la méthode de déploiement utilisée il faut également dissocier le déploiement du run. Pour ce dernier, il est nécessaire d'utiliser des outils d'orchestration tels qu'Ansible, Puppet ou Chef, pour maintenir le système dans un état cohérent. En conclusion, plein de possibilités, beaucoup de discussions et absence de consensus.

OpenStack Application Working Group

Le User Committee OpenStack est composé de plusieurs groupes de travail dont l'objectif est de récupérer les retours d'expérience des différents types d'utilisateurs. Les groupes de travail sont spécialisés dans un domaine particulier :

• Déploiements de plateformes à grande échelle,
• Déploiements dans le milieu scientifiques,
• Sondages utilisateurs,
• Applications "Cloud-aware",
• etc.

La session d'aujourd'hui était consacrée au groupe d'utilisateur "OpenStack Application Working Group". Ce groupe composé de 5 personnes s'est rapidement présenté et a exposé ses différents objectifs.

L'objectif principal est de comprendre les problématiques des développeurs d'applications cloud-ready sur OpenStack. En outre, il cherche à trouver des retours utilisateurs pertinents, afin de remonter des éventuels problèmes de SDK, de documentation, etc, au comité technique. Le groupe cherche également à identifier des fonctionnalités manquantes que l'on retrouve chez les technologies concurrentes comme Amazon Web Services, Google Cloud Plateform ou Microsoft Azure.

Le groupe publie également dans la documentation des exemples réels d'applications nativement compatibles avec le cloud OpenStack.

À terme, en facilitant le développement d'applications sur OpenStack, le groupe cherche à diversifier et faire grandir l'écosystème d'applications "OpenStack Ready".

Si ce sujet vous intéresse, le groupe se réunit sur IRC tous les lundi, à 10pm UTC.

Conférences

1 an de big tent

Durant cette conférence, Thierry Carrez (OpenStack Foundation) et Monty Taylor (IBM) ont pris un peu de recul pour présenter ce qui a marché et ce qui a moins marché avec l'instauration de ce nouveau modèle de gouvernance, plus ouvert.

On peut noter dans les aspects positifs : plus de collaboration, plus de compétition ainsi que plus de réactivité. En revanche, d'autres points sont plus problématiques : l'absence de pré-requis de diversité de contributions autorise l'intégration des projets développés par une seule société (le but étant que le passage vers un statut officiel encourage plus de diversité...), ou encore la difficulté d'intégrer des projets ayant déjà un historique et qui ne sont pas forcément habitués à toutes les "pratiques OpenStack".

Walmart OneOps

Walmart est revenu sur leur experience de migration d'applicatifs vers le cloud. En utilisant leur solution open source OneOps, ils peuvent assurer le déploiement, le passage à l'échelle et l'auto-réparation de leurs déploiements.

La réécriture de leurs applications a souvent été hors de question, mais il ont pu néanmoins migrer en suivant quelques principes simples :

• Ne jamais utiliser d'adresses IP hardcodées, supprimer les communications directes inter-machines pour passer systématiquement par les load-balancers,
• Bannir les systèmes de fichiers partagés tels que NFS.

DEFCON 3: OpenStack Meets the Information Security Department

Durant cette présentation de Solinea, une société d'assistance dans l'adoption des cloud ouverts, James Clark a évoqué tous les obstacles que peuvent rencontrer les déploiements OpenStack liés à la sécurité des grandes organisations.

Celle-ci est généralement moyenne dans les infrastructures legacy, mais très procédurière. Ainsi, l'équipe en charge de déployer un cloud privé se heurte souvent à des restrictions et des process auxquels les employés déjà en place ont souvent trouvé des parades (tunnels, ou tout simplement une relation privilégiée avec un admin) pour passer outre.

Les ports configurés en mode trunk sur les hyperviseurs et control plane sont souvent mal vus de la sécurité également. Pour finir, les ouvertures de flux sont très procédurières et prennent de quelques heures à plusieurs jours.

Il est très important de travailler très tôt avec le CISO, avant même la phase d'architecture/design, afin de l'impliquer aux réflexion nécessaires qui vont l'amener à revoir de tels processus. Les règles peuvent changer très lentement, notamment si les infrastructures sont auditées, voire régulées par des institutions extérieures.

L'authentification gérée par Keystone stocke des mots de passe en local, même si il y a fédération d'identité. Une base redondante de mots de passe fédérés est souvent un nogo pour la sécurité. Ceci a néanmoins été recemment corrigé avec la gestion des domaines par l'API Keystone v3.

Certaines sociétés n'aiment pas ne pas savoir ce qui se cache derrière une IP. Il y a désormais un driver Neutron qui peut se charger de demander des adresses IP à une base IPAM centralisée et renseigner ce à quoi elle correspond.

Pour finir, Solinea édite un produit, Goldstone opentrail auditor, qui se veut être analogue à Amazon CloudTrail. Cet outil permet de logguer tous les appels aux API et modifications effectuées sur une installation OpenStack à des fins d'audit.

Comment devenir un contributeur OpenStack - Advanced

Ildiko Vancsa d'Ericsson, déjà présente à l'Upstream University, nous a partagé sa vision d'un contributeur parfait. Tout d'abord celui-ci doit prendre en main les outils necessaires :

• Launchpad pour les bugs (Storyboard pour ce qui concerne openstack-infra)
• Mailing-lists (on évite les mails en HTML !)
• IRC + logs sur IRC (eavesdrop. Les logs sont importants notamment pour les meetings, auxquels tout le monde ne peut évidemment pas forcément assister.
• Git + Gerrit (code et review)
• Jenkins/Zuul (testing)

Elle a ensuite décrit la bonne façon de se comporter :

• Ne pas systèmatiquement prendre les tâches "faciles" ou "cool". Il y a du "sale boulot" à faire avant tout. C'est une bonne façon de s'intégrer.
• Tout le monde peut faire du code review, c'est même formateur. Cela permet de se faire connaitre des gens qui, justement, postent des patches (et potentiellement font des reviews). Lorsque vous posterez un patch, un reviewer sera plus enclin à relire votre patch si il se rappelle de votre nom que si vous êtes un inconnu. C'est un cercle vertueux.
• Il ne faut pas hésiter à donner des -1 si ils sont mérités ; en revanche il faut rester productif et les justifier. Il faut aussi rester utile : répéter le log de Jenkins ou le commentaire d'un autre reviewer n'est pas intéressant.
• Lorsque l'on reçoit des reviews sur ses patchs, il est positif de répondre rapidement au reviewer pour montrer son intérêt (et limiter l'effort du reviewer si il doit vous répondre ou lire un amendement à votre patch).
• La communauté est gigantesque ; il est préférable de se cantonner à un nombre limité de projets. Pour commencer, approcher un petit projet peut être plus facile (notamment en faisant le "sale boulot" de documentation ou de nettoyage :-)).
• Il est bien vu d'essayer les patchs des gens et leur donner du feedback (Devstack is your friend).

Pour les plus courageux qui seraient tentés de faire des modifications impactant plusieurs projets, l'aspect social est impératif : durant les design sessions il faut rencontrer les personnes clés pour discuter et valider les designs. Sans cela, il est possible qu'un projet accepte les modifications mais que l'autre les refuse ; la quantité de travail perdue (= temps) peut être considérable.

Comment migrer rapidement et efficacement les legacy workloads dans le cloud -par Red Hat-

Lors de cette conférence présentée par Red Hat, la société américaine est revenue sur sa vision de la migration vers le cloud.

Ils ont tout d'abord rappelé, les trois principales raisons d'adoption du cloud :

• Un besoin d'agilité
• La réduction des coûts
• La manageabilité

Si les fondamentaux sont assez simple à imaginer - on parlait ici de l'importance de mettre en place des processus automatisés et réitérables, de l'importance de préparer la migration en amont avec une phase d'analyse avant la phase de design - l'accent a aussi été mis sur l'importance de l'implication d'équipes transverses. Il faut aussi penser à un eventuel rollback si les phases de test suite à la migration ne sont pas concluantes.

Le but d'une migration vers le cloud étant aussi de :

• diminuer le TCO
• éliminer les dépendances envers les fournisseurs
• accélerer le provisionning
• livrer les services plus rapidement

Maintenance des branches stables d'OpenStack

Trois core reviewers d'IBM, HP et Red Hat nous expliquent que les distributions (Helion, Fuel, RHOSP, ...) sont généralement basées sur la release n-1 d'OpenStack, que leurs contrats de support vivent bien plus longtemps que le support upstream et que l'application des correctifs de sécurité (security fixes) est une exigence de leurs Clients. Pour ces raisons, la maintenance et le support sur une longue période des releases successives d'OpenStack est stratégique. Et c'est la toute la pertinence des "branches stables" qui subissent au quotidien le même workflow d'intégration continue que la branche "master". A titre d'exemple, la branche "Mitaka", dernière en date, se voit appliquer, pour tester les "backports" depuis "master" dont elle fait l'objet, plus de 300 000 tests par jour avec un taux de succès proche de 99% !

Orchestration

La description de l'infrastructure nécessaire au "run" d'une application est généralement réalisée grâce à l'orchestrateur intégré d'OpenStack, Heat.

Grâce à un tout nouveau composant, le "tosca parser", il est maintenant possible d'exprimer en langage TOSCA, un standard émergeant permettant grâce à un DSL (Domain Specific Language) à syntaxe YAML, non seulement de décrire une infrastructure mais également les besoins d'une application. Le "tosca parser" est un sous-projet de Heat et son intégration dans OpenStack avance bon train et un plugin pour Horizon est prévu dans la prochaine release d'OpenStack, Newton. Le CERN, second contributeur sur le "tosca parser" après IBM, a récemment fait le choix de Tosca pour décrire les applications et leurs infrastructures.

Upgrader OpenStack en sautant une release (Suse)

Des ingénieurs de Suse nous affirment que c'est possible... mais que ce n'est pas simple. En effet, il s'agit d'une opération essentiellement manuelle, à l'issue incertaine et dont le niveau de difficulté dépend de la quantité de ruptures entre les releases (schémas bases de données, fichiers de conf, etc.). Les ingénieurs de Suse en profitent pour envoyer un "call for action" à l'attention de la communauté : poursuivre l'uniformisation des fichiers de configuration et prévoir un mécanisme d'upgrade automatique de ces mêmes fichiers.

Petit tour d'horizon du "Booth Crawl"

Le booth crawl, comme à l'habitude, clôture la première journée du summit et marque par la même occasion l'ouverture du Marketplace.

Les allées du Booth Crawl

Un concert très... Texan.

Le stand de Mirantis

Le stand d'Ubuntu/Canonical

• Le deuxième jour de l'OpenStack Summit, c'est par ici !

L'équipe Osones