Standardisation des API

C'est un rêve pieux de penser que les éditeurs majeurs (Amazon, Rackspace, VMWare, etc.) vont se mettre d'accord pour unifier leur API de services IaaS, malgré de multiples propositions de normalisation (OGF avec OCCI, DTMF avec un projet dans le pipe, etc.) engagées.

Après le Design Summit de Diablo (S1 / 2011), il avait été décidé, semble-t-il d'engager le blueprint pour l'intégration de l'API OCCI dans les releases à venir d'OpenStack. Mais malgré cette volonté, il ne semble pas que cela se soit traduit dans les faits. Impossible de trouver dans la liste de tous les blueprints Nova, un seul blueprint relatif à OCCI, ni même dans l'analyse du code (essex-3). A ce jour, 2 seules API sont couvertes par Openstack: EC2 & OpenStack (c.à.d, en gros, l'API de Rackspace).

Depuis quelques mois, le nombre d'environnements de qualification (bac à sable) est important (Enovance / oct-2011, HP Cloud Services / dec-2011, TryStack / feb-2012, etc.). Il a été intéressant d'utiliser les ressources et les services de ces solutions avec les API EC2 et OpenStack. Pour EC2, il suffit d'utiliser Hybridfox et pour les API OpenStack, on peut faire le tour avec ClientREST. Ces tests ont permis et d'apprendre :

• l'alignement du bac à sable HP Cloud Services vis-à-vis des 2 API avec l'identification initiale via KeyStone pour OpenStack. A titre d'information, la solution d'HP est stable, conviviale et  très proche d'une production. Je me suis appuyé sur la hotline (chat) pour régler un problème sur l'API EC2 (info obtenue immédiatement). Reste à savoir, comment ils vont monter de version. Soit via un environnement parallèle, pour ensuite arrêter l'environnement Diablo et récupérer les ressources HW pour ajouter à l'environnement Essex, soit par un arrêt de services plus ou moins long.

• les évolutions fonctionnelles portées à Hybridfox (release : 1.6.000170) avec : ELB, Monitoring, Cloud Formation, etc. 

 

• la volonté d'Enovance de déployer, en avance de phase, la release Essex Beta (essex-4). Celle-ci va être ouverte à des béta testeurs à la mi mars prochain.

Bien qu'ayant appliqué correctement les consignes des guides de développements de l'API Keystone, je ne suis jamais parvenu à requêter correctement les ressources comme /users/{user-id}, /users/{user-id}/roles, etc. A l'aide du jeton, je suis arrivé à utiliser la quasi totalité des autres ressources (nova, swift, etc.)  à l'aide du jeton de session d'une durée de vie de 24h. A vrai dire, il suffit de relancer la requêtes POST de la ressources /tokens avec le corps du body JSON adéquat (endpoint, username, password & tenantId) pour retrouver 24h d'autonomie.