Why I use RunAbove API instead of OpenStack

Why I use RunAbove API instead of OpenStack

Published Sept. 29, 2015 in Cloud - Last update on Sept. 30, 2015.

I recently added RunAbove driver to libcloud codebase and Kami, one of the project owners, asked me why I use the custom RunAbove API instead of the OpenStack one. RunAbove is an OpenStack based cloud and I made the choice to use them API instead of the standard one. It has been accepted in libcloud but I want to write here why opt for this way.

1. It is pretty easy to use

Deal with several regions is sometimes painful with some OpenStack clouds. Keystone can help to know where are all components of the cloud and with tools like nova-client ease everything, but all endpoints are contacted individualy so it does not appear as a unified interface. RunAbove's API has the benefit to encapsulate all services in a single interface.

This unique endpoints allows to make cross-region requests like list all instances or volumes. All this API is not well documented but very easy to understand with online console. This single-page app gives a listing of all actions available, their methods and parameters used. And best, it allows to launch requests, see response, requests and responses' headers. A little like Google has made with their API Explorer.

2. It is customized for more services

A next plus is the avaibillity to use other RunAbove's services with this interface, one more unification. This cloud provider purposes a variety of experiemental and stable services, all are generaly available from this API.

For example, CORS support can only be enabled from this endpoint.

3. OpenStack API is usable under this one

I must admit some actions are not yet implemented and use an OpenStack endpoints may be mandatory. Runabove provides in their API an URL to get your catalog and an authentication token.

Comments

No comments yet.

Post your comment

Comment as . Log out.