Osones vous propose de vivre le Summit OpenStack 2016 de Barcelone !

¡ Buenas tardes !

Denière journée du Summit pour les équipes Osones. Journée par ailleurs moins chargée que les précédentes.

CLI unifié (OSC) pour OpenStack, Chen Tang (chen.tang@easystack.cn), Rui Chen (chenrui.momo@gmail.com)

Tout d'abord, rappelons que la CLI (Command Line Interface) d'OpenStack fournit à la fois un outil de type "ligne de commande" pour les administrateurs et une API (Application Programing Interface) Python pour les développeurs.

Historiquement, il existe dans OpenStack autant de commandes que de projets (au sens OpenStack) : keystone, nova, neutron, glance, cinder, etc. Et ceci a entraîné les faiblesses suivantes :

• des fonctionnalités dupliquées : par exemple, image-create se trouve dans la CLI nova et dans celui de glance
• des conflits de noms : par exemple, 'flavor' existe dans la CLI nova et dans celui de neutron mais désigne des entités différentes
• des commandes difficiles à maintenir et à debugguer
• beaucoup de code dupliqué

Ces faiblesses ont largement justifié le développement d'une CLI unifiée, officiellement nommée OSC (OpenStack Client), qui soit à la hauteur des ambitions d'OpenStack.

OSC possède les caractéristiques suivantes :

• il propose une commande unique nommée tout simplement "openstack", qui possède par aiileurs un mode interactif
• comme l'ont souhaité les Utilisateurs, OSC utilise un langage orienté "fonctionnalité" ou "service" plutôt que "projets". Par exemple, il ne parle pas de "nova" mais de "compute", pas de "neutron" mais de "network"
• ses fonctionnalités sont facilement extensibles via un mécanisme de plugins

Du point de vue interne, les catégories de commandes (compute, network, image,...) correspondent à des classes Python. Six commandes "core" sont implémentées nativement dans OSC. Toutes les autres commandes le sont via le mécanisme d'intégration et de découverte de plugins (openstack.cli.extension).

Entre autres avantages, ce CLI unifié propose un format consistant et prévisible : $ openstack options-globales object-1 action objet-2 arguments

Démonstration par l'exemple : instanciation d'un serveur avec un volume disque bootable attaché

• avec l'ancien CLI :

    $ glance image-list
    $ cinder create --image
    $ nova flavor-list --extra-specs
    $ neutron net-list
    $ nova boot --boot-volume --nic --flavor

• avec OSC :

    $ openstack image list --long
    $ openstack volume create --image
    $ openstack flavor list --long
    $ openstack network list --long
    $ openstack server create

Plus simple, plus cohérent, plus homogène et surtout orienté fonctionnalités. Exit le nom du projet dans la ligne de commande !

Parions que l'adoption d'OSC va s'accélérer et qu'il fera rapidement l'unanimité chez tous ceux qui consomment des API OpenStack au quotidien.

Ceph, Now and Later: Our Plan for Open Unified Cloud Storage

Dans cette présentation, Sage Weil nous a donné l'état actuel du projet Ceph ainsi que les nouveautés à venir. De nouvelles versions de Ceph sortent tous les six mois, la dernière sortie étant Jewel (LTS) au printemps dernier. Cet automne, Kraken sortira et apportera de nouvelles fonctionalités. Suivra Luminous au printemps prochain, une release LTS.

Kraken sera la première release avec un code "stable" pour le nouveau moteur de stockage BlueStore : l'architecture logicielle devrait être fixée, cependant la fonctionalité sera très probablement encore considérée comme expérimentale.

BlueStore est un moteur de stockage qui doublera les performances en écriture en RBD grâce à son design : en effet, les OSD ne reposeront plus sur un système de fichiers comme aujourd'hui (celui recommandé étant XFS) : les blocs seront écrits directement sur le périphérique de stockage (disque dur, ssd, nmve, ...) sans passer par un journal. Les metadata seront stockées dans une nouvelle base de données interne. Vous pouvez aller lire l'article de Sébastien Han pour plus de détails.

Kraken apportera également une nouvelle implémentation au niveau des communications réseau, ainsi que des implémentations "pluggable". Lors du profiling du temps CPU passé par Ceph à répondre à des requêtes, une portion non négligeable de temps CPU est passée dans l'encapsulation réseau du trafic. Parmi les implémentations pluggable, il sera possible d'utiliser DPDK ou RDMA (avec du matériel adéquat).

Luminous, prévue pour le printemps 2017, apportera un support multi MDS pour CephFS. Il devrait également apporter le support de l'erasure coding pour RBD & CephFS, ce qui améliorera encore le TCO d'une solution de stockage basée sur Ceph.

Il est également prévu de sortir certaines fonctionalités non critiques aujourd'hui remplies par les démons ceph-mon pour les faire exécuter par un nouveau démon : ceph-mgr (pour "Ceph Manager"). Ceci permettra d'ajouter ce nouvelles fonctionalités à ce démon sans compromettre la robustesse de ceph-mon. Sont prévues par exemple les commandes "ceph top" et "rbd top" qui pourront afficher des statistiques plus fines sur les I/Os du cluster. Il est également prévu d'ajouter des fonctionalités de management de plus haut niveau :

• Fonctionalités de QoS, par type d'I/Os (est-ce du scrub ? une i/o cliente ?), par pool, par client (VM)
• RBD ordered writeback cache
• Radosgw indexing (multi site)

Le cloud chez Volkswagen

La motivation de ce grand groupe international pour passer au cloud est la nécessité d'avoir une solution IT qui s'adapte aux défis actuels : l'industrie automobile évolue énormément aujourd'hui, le changement du business model demande de nouvelles solutions IT pour répondre à ces pratiques.

Pour répondre à ces besoins, les entités de Volkswagen déploient de nouveaux labs comme :

• Data lab : algorithm and technology evaluation
• Digital lab : software development and digital consumer solution

Chaque lab a besoin d'une IT fiable et disponible rapidement.

Les clés du succès d'un projet cloud selon Volkswagen sont :

• Mettre les développeurs de son côté, adapter les workflows ;
• Le cloud doit être une stratégie du groupe ;
• Communiquer/convaincre les informaticiens et le métier, tout le monde doit trouver son intérêt dans le projet ;
• Savoir répondre à la question: "Pourquoi avoir un cloud privé ?" ;
• La principale cause d'échec du cloud est "le non-changement des process dans les opérations" ;
• Impliquer la direction juridique dès le début.