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 2 et le jour 3 !

24h de vol plus tard...

Pour la première fois, cette nouvelle édition de l’OpenStack Summit atterrit à Sydney. Malgré ce long voyage, nous sommes 7 experts à partir en Australie pour vous faire vivre l'OpenStack Summit !

C'est dans un centre de conférence flambant neuf, ouvert il y a moins d'un an, qu'a lieu ce 16ème Summit. Comme pour tous les Summits en dehors du continent nord américain, l'audience est moins nombreuse, plus de 3000 personnes sont néanmoins annoncées.

La Keynote

Ouverte par le fondateur du User Group OpenStack Australien, la désormais traditonnelle Keynote d'ouverte se dévoile après une vidéo mettant en avant la communauté de ce projet OpenSource.

Cette rapide introduction est suivie de près par l'appariton de Mark Collier (COO de la fondation OpenStack) et de Lauren Sell (VP de la fondation OpenStack). Ces derniers, après être revenus sur les fondamentaux d'OpenStack pour les Australien participant à cet événément pour la première fois, présentent un nouveau programme : PassPort, une nouvelle page d'informations destinée à mettre en valeur les clouds publics basés sur OpenStack.

A noter : Monty Taylor présente Zuul

Le premier intervenant exterieur à la fondation est Monty Tailor, membre du staff technique de Red Hat, présentant Zull v3. Cet outil de CI/CD natif OpenStack et Ansible à dabord été développé au sein de la communauté OpenStack, et cherche désormais à être utilisable pour les utilisateurs "non-openstack". Zull V3 n'est cependant pas nouveau, puisqu'il a déjà fait l'objet d'une conférence lors du Summit OpenStack Barcelone. Trois conférences sont prévues à ce sujet cette semaine pour aller plus loin dans le projet.

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

- What's new in OpenStack? Queens Roadmap

Anne Bertucio de la Fondation OpenStack nous a présenté la RoadMap pour la prochaines release Queens. Cette version a comme focus :

• l'expérience utilisateur
• la scalabilité
• la modularité
• la résilience
• La sécurité
• l'interoperabilité

Nous avons eu le droit à un résumé avec la présentation de 10 nouveautés pour Queens :

• Mises à jour rapides : amélioration de la gestion d'OpenStack pour réussir a mettre à jour jusqu'à la version actuelle plus rapidement.
• Faire de la documentation sur les roles based access control (RBAC). Actuellement il est très difficile de changer les roles (policy.json) car aucune documentation exhaustive n'existe.
• OpenStack-Helm dont nous parlons plus bas (qui apporte une facilité de gestion pour des cas d'usage tel que les conteneurs et le edge computing).
• Le projet Masakari qui fournit des VM avec haute disponibilité arrive sur Openstack.
• Le mode rescue de Ironic (qui apporte de la facilité de gestion et une plus grande résilience).
• L'interface web Horizon permettra le drag and drop de ressources Heat.
• La prise en charge des vGPU.
• Permettre à Cinder d'attacher un volume à plusieurs instances simultanement.
• Le repo Swift contiendra les API S3.
• OpenStack LOCI est le projet qui a pour vocation de rapidement contruire des images légéres compatibles OCI (Open Container Initiative) des différents services OpenStack.

- to k8s or not to k8s, your OpenStack Control Plane

Robert Starmer, expert en intégration cloud chez Kumulus Technologies est venu nous parler de l'implémentation du control plane OpenStack sur Kubernetes. Après un bref rappel sur ce qu'est Kubernetes et ses composants clés (pod, deployment, service discovery, statefull sets...) ainsi que ses prérequis de fonctionnement (du réseau, un service de load balancing, un système de stockage distribué, ainsi qu'un système de monitoring et d'alerting).

Avant de mettre le control plane d'OpenStack sur Kubernetes il faut déjà savoir queltype de plateforme cloud on souhaite monter. En effet, il n'est pas nécessaire dans le cas de certains déploiements d'ajouter une couche de compléxité supplémentaire. Mais la compléxité de Kubernetes peut devenir un atout dans le cas déploiement de plateforme multi-site nécessitant une une forte scalabilité et un haut niveau de résilience. Kubernetes permettra également de gérer plus facilement les upgrades graĉe à ses fonctions natives de rolling upgrades.

Par où commencer si on souhaite utiliser Kubernetes pour orchestrer mon control plane ?

Il y a deux choix possibles : OpenStack-Helm ou Kolla-Kubernetes

OpenStack Helm :

• fourni des templates (des "charts") pour les principaux services (ex : Nova)
• se base sur des outils tiers pour le packaging des images (l'objectif étant de supporter les conteneurs Docker ou non Docker comme LXC par exemple)

Kolla-Kubernetes :

• Plus grande granularité que les templates de Helm (exemple : Nova-API, Nova-Server ...)
• Tire parti du travail réalisé avec le projet Kolla pour la création de conteneurs, la gestion des configurations, les images de conteneurs ...

Il faut en revanche s'assurer avoir certaines compétences :

• dans l'intégration des services Kubernetes
• dans la gestion de l'intégration de conteneurs (docker ou LXC/LXD selon votre choix)
• sur Helm --> les templates Helm sont en goland
• sur le monitoring

- Networking avec VM, baremetal et container

Lors d'une courte presentation, Mitchell Jameson (contributeur ironic-neutron) a montré qu'il est possible de faire communiquer avec Neutron des VM, des serveurs bare-metal et des conteneurs. Neamoins, il est necessaire d'avoir un equipement hardware de SDN à cause de la nature des serveurs baremetal.

Les composants suivants servent d'interface vers Neutron :

• Pour les conteneurs : Kuryr
• Pour le bare-metal : Ironic
• Pour les VM : Nova

Nova :

$ openstack server create ... --nic net-id=$NETWORK_ID

Ironic : dans la conf ironic, mettre les variables suivantes enabled_network_interfaces et default_network_interface à neutron

$ openstack baremetal port create ... --local-link-connection switch_id=$SWITCH_ID --local-link-connection switch_info=$SWITCH_INFO --local-link-connection port_id=$SWITCH_PORT $MAC_ADDRESS

Kuryr : dans le conf kuryr, configurer la section neutron avec les creds pour utiliser le service.

# docker network create -d kuryr --ipam-driver=kuryr --subnet=$SUBNET --gateway=$GATEWAY -o neutron.net.name=$NETWORK_NAME $NETWORK_NAME
# docker run -it --net $NETWORK_NAME $DOCKER_IMAGE

- Truly non-intrusive cinder backup for mission critical systems (lightning talk)

Dipak Kular Singh (NEC Technologies) Beaucoup de monde dans la salle pour assister à ce "lightning talk" de 10 minutes à peine dédié à la problématique de la sauvegarde des données critiques hébergées sur des volumes Cinder. Cette affluence montre que la sauvegarde de données reste un vrai sujet ! Sauvegarder un volume attaché à une instance est simple : la technique consiste à créer un "snapshot" du volume, via l'API Cinder, puis à sauvegarder ce snapshot. De plus, cette technique assure le caractère "Point-In-Time" du backup. Seulement voilà, le système de buffer cache de Linux vient contrarier cette méthode. En effet, ce système, conçu pour améliorer les performances des I/O disque et non pour assurer l'intégrité des données, ne garantit pas que les données sont écrites sur le disque en respectant l'ordre d'écriture déterminé par l'application qui les a produites. La conséquence de ceci est l'apparition du phénomène "out of order write" qui peut empêcher le redémarrage de l'application après une restauration du backup. Suffirait-il de démonter le système de fichiers (linux umount) et détacher le volume (cinder detach) ? Oui, mais :

• ces opérations sont, du point de vue de l'application, intrusives par nature
• elles sont incompatibles avec les applications critiques ne supportant pas le moindre arrêt de service.

Un début de solution ? contrôler le mécanisme de "buffer cache" le temps d'exécuter le snapshot Cinder en réglant la valeur du paramètre /proc/sys/vm/dirty_bytes du kernel. Vous souhaitez en savoir plus ? https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Forum

- Présentation Barbican / Castellan

Nous avons pu assister en petit comité à la présentation de Dave McCowan, (PTL sur Barbican), et Ade Lee (Red Hat). Le stockage des secrets est un sujet critique dans tout déploiement d'infrastructure. OpenStack peut amplifier cette complexité part son approche multi-tenant. Barbican est un projet qui a été pensé pour répondre au besoin de stockage sécurisé des secrets OpenStack de manière centralisée.

Articulé autour d'une API REST, il peut évoquer Vault ou n'importe quel service de gestion de secret par API du marché. Le principe est similaire : On stocke des secrets (clés privées SSH, mots de passe, clés de chiffrement de volumes, certificats X.509...) en générant une URI pour chaque secret permettant de le récupérer depuis d'autres applications. On ne distribue plus les passwords sur les hosts, on les met à disposition via une API. Les appels peuvent se faire directement via l'API REST de Barbican ou via le client openstack secret.

Le projet se démarque toutefois par quelques aspects notables :

• Intégration complète à OpenStack : communication avec Keystone notamment pour la partie Policy/RBAC (AuthZ/AuthN)
• Abstraction du backend de stockage des passwords : on peut opter pour de simples fichiers, une base de données NSS, un HSM via PKCS#11 ou même Vault via le système de storage plugins
• Générations sécurisées des passwords au moment du provisionning
• Gestion de l'aspect éphémère des passwords d'un environnement Cloud

Barbican vient avec Castellan, une API multi-backend en cours d'intégration à Oslo qui permet de communiquer non seulement avec Barbican mais aussi directement à des produits comme Vault de Hashicorp ou Custodia si nécessaire.

- OpenStack-Ansible feedback

Traditionnelle session d'échanges entre développeurs et opérateurs, ici concernant l'outil de déploiement OpenStack-Ansible (OSA).

OSA est aujourd'hui utilisé par de nombreux déploiements de production, les questions évoquées concernent donc des sujets plus avancés ou du moins des besoins particuliers. Un point particulièrement intéressant discuté lors de cette session est la question des installations hors ligne. Aujourd'hui, ceci est loin d'être évident : OpenStack-Ansible va chercher sur Internet beaucoup de choses, paquets APT, Python, ou encore dépôts Git, parfois initialement, parfois de manière régulière. Il est possible via des variables de redéfinir les emplacements où OpenStack-Ansible se connecte, donc avec des miroirs locaux, il est envisageable de faire un déploiement hors ligne. Dans la pratique, il existe encore quelques obstacles plus ou moins importants, mais contournables.

Néanmoins les développeurs envisagent un changement dans le process de déploiement OSA : il s'agirait de concentrer au début la construction des artifacts (repo_build) nécessaires, et ainsi l'ensemble des connexions nécessaires à Internet. Ces travaux doivent se dérouler pendant le cycle de développement Queens qui a déjà débuté, et permettront ainsi d'améliorer la capacité d'OSA à fonctionner hors ligne.

On continue sur notre lancée : par ici pour le JOUR 2 et le jour 3 !

La Team Osones