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

• Vous pouvez retrouver sur le blog le récit de la première journée de l'OpenStack Summit Austin et celui de la deuxième journée.

• Nous avons également mis à jour nos supports de formation OpenStack et Docker. Ces supports sont bien entendu en français, et disponibles sous licence Creative Commons BY-SA !

Mercredi, on passe dans la phase 2 du summit. Terminé les keynotes, on entre dans le dur du sujet dès 9h. Et ce malgré la soirée StackCity Party de la veille qui a vu des centaines d'OpenStackers déferler dans tout Rainey Street pratiquement entièrement privatisée pour l'occasion. :-)

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

Lors de la deuxième et troisième journée du summit, nous avons suivi les discussions autour d'un éventuel statut pour les contributeurs actifs non développeurs.

On peut différencier deux types de profils qui contribuent largement à l'adoption et la démocratisation d'OpenStack sans produire de code :

• Les Opérateurs, qui contribuent à l'adoption de la technologie par la nature même de leur travail, et à la communauté par différents outils (ask.openstack.org, triage de bug, etc.) ;
• Les Communautaires, qui organisent des événements comme les Meetups ou les OpenStack Days.

Jusqu'à ce jour, seules les contributions de code permettent d'être reconnu auprès de la fondation et permettent d'accéder au statut de contributeur actif. Ce statut permet d'avoir une voix pour élire le Technical Committee (TC) et d'obtenir un pass gratuit pour les summits tous les 6 mois.

Les discussions sont en cours auprès du User Committee (UC) afin de créer un nouveau statut reconnaissant les efforts des Opérateurs et Communautaires. Ces contributeurs pourraient accéder à un statut d'AUC, Active User Contributor, permettant d'obtenir un droit de vote pour élire le UC.

Aujourd'hui les 3 membres du UC sont appointés par le board et le TC. Un système de vote pour élire le TC est en discussion.

Le groupe de travail "Non-ATC" réfléchit sur les nouvelles métriques permettant d'accéder au statut d'AUC. Vous pouvez voir le document de travail ici.

À terme, voici la liste des différentes fonctions qui permettraient d'être éligibles à ce statut :

• Organisation d'un groupe d'utilisateurs officiel ;
• Participation remarquable à un groupe d'utilisateurs officiel ;
• Modération d'un meetup Ops ;
• Contribution d'un repository géré par la gouvernance (repositories ops, user stories, etc) ;
• Contribution au magazine Superuser (articles, interviews, user stories, etc.) ;
• Modération active sur ask.openstack.org.

On soulignera la qualité des discussions des sessions animées par le User Committee qui prend des décisions pertinentes et rapides sur la création de ce nouveau statut.

Design Summit

Visibilité des images dans Glance

Cet après-midi, quelques sessions consacrées à Glance. Faisons un focus sur celles consacrées au partage d'images.

Aujourd'hui, l'API v2 de Glance autorise un statut public pour les images, par défaut uniquement définissable par l'administrateur. En outre, un utilisateur peut ajouter des membres à son image (image-member), c'est-à-dire des tenants, afin de leur donner accès. L'image private devient alors partagée (mais son statut reste "private"). Pour éviter le risque de spam, un appel API "lister les images" ne renverra que ses propres images et les images publiques. Les images partagées issues d'un autre tenant doivent être manuellement "autorisées" afin d'apparaître dans la liste.

Seulement, le statut public a habituellement une connotation "officielle" et sa définition reste donc un pouvoir restreint à l'administrateur. Il manque alors la possibilité pour un utilisateur lambda de partager son image avec tout le monde, plutôt qu'avec uniquement un ou quelques tenants. C'est donc l'objet de la proposition discutée dans cette session : ajouter un statut "community". Par la même occasion, le statut private avec des image-members serait désormais désigné shared, pour plus de clarté.

Le Hilton où se déroulent les sessions design.

Conférences

Faciliter les tests des nouvelles versions d'OpenStack : déploiement sous forme de micro services conteneurisés

Si l'on prend un peu de hauteur, on peut facilement se rendre compte que les fonctionnalités "control plane" d'OpenStack sont une collection de services unitaires ultra-spécialisés. Et d'ici à parler de "micro" services et à envisager leur déploiement via des conteneurs, il n'y a qu'un pas que Miguel Zuniga, le speaker de cette conférence, n'hésite pas à franchir. Poussons encore un peu plus le concept et faisons preuve d'audace : puisque le control plane d'OpenStack est une application comme une autre, pourquoi ne pas placer son déploiement et son exécution sous le control d'une plate-forme PaaS telle qu'OpenShift par exemple, qui s'appuyerait sur Kubernetes pour gérer des ensembles de conteneurs à base d'images Docker hébergeant les micro-services en question ? (ouf...)

Voici la recette :

1 - fabriquer une image Docker pour chacun des services OpenStack (keystone, nova, glance, horizon,...)
2 - pousser ces images dans votre repository git (...)
3 - créer les templates OpenShift correspondant aux micro services
4 - déployer les micro services sur les environnements souhaités
5 - tester, tester et encore tester

Une nouvelle version d'un core service à déployer ? Reprendre à l'étape n° 1 !

Les conteneurs et le PaaS vous font gagner au passage souplesse de déploiement, scalabilité et upgrades du code OpenStack facilités.

Simple comme bonjour n'est-ce pas !

OpenStack a 6 ans, l'âge de raison ?

Table ronde avec Canonical, Scality, Comcast et HPE

Tout d'abord, les quatre intervenants présents à cette table ronde reconnaissent que les "core" services d'OpenStack (compute, storage, network) fonctionnent bien et qu'ils sont "production ready". Par ailleurs, les équipes de développement de Scality, éditeur d'une technologie logicielle de stockage concurrente de Swift et Ceph, nous confirment que les processus et outils permettant l'apport de code neuf par les contributeurs sont au point et très efficaces. Mais le ciel n'est pas si bleu au-dessus de l'OpenStack land et des critiques portant sur d'autres points sont formulées. Ainsi, toujours selon Scality, les éditeurs de logiciels ont des difficultés, faute de roadmap générale, à déterminer où ils doivent porter leurs efforts de développement concernant l'intégration de leurs technologies dans OpenStack.

Pour Mark Shuttleworth (Canonical), la fondation OpenStack doit travailler sur le développement des "core" services et du référentiel RefStack et de sa boîte à outils (https://refstack.openstack.org). Le point de vue de Comcast consolide l'avis de Mark : OpenStack doit se concentrer sur son cœur de métier, à savoir l'orchestration d'infrastructures physiques. Si l'on admet qu'OpenStack est le kernel du cloud, alors pourquoi devrait-il plus se préoccuper des services de plus haut niveau que le kernel Linux ne s'occupe des applications userland telles que Nginx ou MongoDB ?

La question reste ouverte à ce jour mais on l'aura compris que certains acteurs de l'industrie, et non des moindres, ont déjà forgé leur conviction...

Tenant networks vs provider networks

Cette conférence reprend les principes de base entre les tenant networks et les provider networks et détaille les avantages de l'un et l'autre pour démontrer en quoi l'utilisation de provider networks dans le cadre d'un cloud privé apporte de la simplicité. En effet, l'évolution des security groups dans Neutron, qui a permis de rapprocher la sécurité au plus proche des workloads, rend possible l'utilisation de provider networks partagés entre de multiples tenants.

Pour rappel, les tenant networks sont des réseaux isolés dans un namespace réseau et qui ne sont donc visibles que du tenant dans lequel ils ont été créés. Ces namespaces autorisent notamment que deux tenants possèdent chacun un réseau utilisant le même bloc CIDR. En revanche, un provider network est lié à une interface physique et donc au réseau physique. Un provider nework possède toujours une gateway sur le réseau physique. Ils sont notamment utilisés pour créer les réseaux externes qui doivent permettre de sortir de l'infrastructure OpenStack.

De par leur aspect virtuel, les tenant networks apportent de la souplesse. La communication entre tenant networks (d'un même tenant évidemment) se fait via la création d'un routeur virtuel. Celui-ci se sert du SNAT pour faire sortir les instances du réseau et à moins que les instances disposent d'une floating IP, elles ne sont pas joignables de l'extérieur, "protégées" par le NAT.

Ceci pose un premier problème. Bien que le NAT apporte une gestion ultra simplifiée du plan d'adressage réseau (puisque vous ne vous souciez plus de savoir si votre bloc CIDR est déjà utilisé autre part), il casse la communication end-to-end, complexifie le fonctionnement de certaines applications comme IPSec et demande paradoxalement de maintenir une table IPAM concernant les floating IP.

A contrario, les provider networks, liés au réseau physique, sont bien moins flexibles. Si ceux-ci sont mappés sur des VLAN, il vous faut donc disposer d'un moyen de provisionner ces VLAN sur votre infrastructure physique. Ce n'est pas impossible, mais il s'agit d'un complexité supplémentaire.

Pour le moment, le routage des provider networks est réalisé de manière statique par des routeurs en bordure du Cloud. À terme, Neutron implémentera la fonctionnalité de BGP speaker ce qui permettra de router plus facilement les provider networks.

La fonctionnalité BGP peut également avoir du sens pour les tenant networks suivant la technologie de segmentation utilisée, mais dans le cadre de VXLAN ou de GRE, les réseaux des tenants peuvent s'overlapper et BGP seul ne résout pas ce problème. De plus les tenant networks ne sont pas censés être connus à l'extérieur du Cloud, et sont justement masqués par les fonctionnalités de SNAT et de DNAT fournies par Neutron.

En IPv6, c’est un autre débat, puisque il n'est pas prévu d'offrir la possibilité de faire du NAT, le but étant de s'en débarrasser au maximum. Dans le cadre de l'IPv6, BGP permet d'offrir un routage dynamique et une connectivité de bout en bout, des tenant networks vers le reste de l’infrastructure et l'Internet.

Orchestrating Cross-cloud Applications with Murano

Alexander Tivelkov & Craig Peters @Mirantis

Murano est un catalogue d'applications cloud. Il permet aux développeurs de publier leurs applications en mode clé en main. Murano permet également d'hybrider entre les fournisseurs de composants cloud.

Hybrider permet notamment :

• De ne pas mettre tous ses œufs dans le même panier, et de palier à un éventuel incident majeur d'un provider ;
• De profiter de spécificités fournies par certains clouds (par exemple un load balancer avec une feature spéciale, des configurations matérielles spécialisées, ...) ;
• De répondre à des exigences légales (traitement de données sur territoire national notamment) ;
• De consommer les ressources au meilleur coût.

Murano dispose d'un mécanisme de classes : d'un point de vue développeur, on peut vouloir une node pour faire tourner un worker. Une node peut être un conteneur, une VM ou un serveur physique. Une VM peut être sur OpenStack, AWS ou Azure.

De la meme façon, un utilisateur demandera "une grosse base de données" ; un ingénieur demandera une base de données SQL avec un stockage fournissant X IOPS.

Ces classes héritent les unes des autres, en décrivant leurs spécificités.

Le mécanisme de design by contract permet à Murano de proposer la fourniture de plusieurs applications répondant aux inputs. Il prends également en compte les flavors, permettant ainsi de choisir le fournisseur de cloud à utiliser.

Le packaging d'applications se fait à l'aide d'un langage déclaratif. Cela permet d'éviter le code imperatif lancé avec des privilèges sur l'infrastructure OpenStack.

La communication entre les instances dans le cloud privé et Murano est effectuée par un bus de message. La communication IP entre les instances de différents clouds peut se faire grâce aux VPC ou même avec un VPN. Murano s'occupe alors de configurer OpenVPN.

Overcoming Challenges in Promoting OpenStack Within Your Organization

Lors de ce vBrownBag, Mathew Varghese de Cisco a donné des conseils à adopter pour promouvoir OpenStack au sein d'une organisation de grande taille.

• Identifier les parties prenantes du projet pour comprendre leurs préoccupations : CEO (pérénité de l'entreprise, avantages compétitifs, business model), équipes projet (expérience client, TTM), ingénieurs (efficacité, agilité), exploitation (standardisation, stabilité)...
• Identifier les leaders ; les choix technologiques sont souvents tranchés par le haut du management

Lorsque l'on se retrouve confronté à des gens sceptiques, ou même opposés au projet, il recommande :

• De mettre en avant l'open source avant OpenStack : absence de vendor lock-in ;
• De mettre en place l'OpenStack pour les nouveaux projets & nouvelles fonctionnalités d'abord, pas pour replacer un existant (l'impact sur les personnes concernées pouvant déclencher des réactions d'opposition très fortes) ;
• Sociabiliser avec des OpenStackers d'autres entreprises afin d'échanger conseils, avis & stratégies ;
• D'installer une infrastructure de démonstration.

Léo, Romain, Kévin.

• Retrouver le sommaire de ce dossier sur le récit de la première journée de l'OpenStack Summit Austin.

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

L'équipe Osones