xPlore.Cloud HyBench Developer Documentation


  • This is the HyBench Developer documentation which is meant to help a developer tasked with integrating target clouds into the xPlore.Cloud Hybrid Cloud Framework.
  • If you are a DevOps user and want to learn how to use the xPlore.Cloud Self Service Portal, you should visit xPlore.Cloud User Documentation.
  • On the other hand, if you are a developer tasked with customizing/rebranding the Self Service User Portal, you should visit xPlore.Cloud API Documentation.


xPlore.Cloud is a unique tool to quickly build an orchestration layer for an arbitrary hybrid cloud. It is completely cloud agnostic and provides a very quick, efficient and predictable way to create a self service portal with any number of participating public and/or private clouds like AWS, Azure, GCP, OpenStack etc, as well as raw hypervisors like VMWare, KVM, Xen etc.

Base concepts and terminology

  1. Cloud Access Server (CAS): A Cloud Access Server (CAS) is a Ubuntu 14.04 virtual machine that has two web applications pre-installed. One serves as the production and the other as the development server where developers develop code with the help of the HyBench development environment available on the xPlore.Cloud front-end. A CAS plays the role of a broker between the xPlore.Cloud front end and the participating Clouds or hypervisors.
  2. Feature: At a very basic level, a Feature simply corresponds to a similarly named python source file on the CAS. So if you named your feature foo, say, you will find a file called foo.py has been created within the /var/www/xcloudclientapidev/xcloudclientapi/feature_commands directory on your CAS. You will notice that the file comes preloaded with a number of python function definitions, viz., create, readall, readone, remove, resync and jobstatus. This is the boilerplate code that the HyBench tool creates for you. At a functional level, a Feature, would typically correspond to a resource type on the target cloud(s)/hypervisor(s), e.g. Virtual Machine, Virtual Disk, Virtual Network Interface, Firewall Rule, Load Balancer, etc.
  3. Action: Again at a very basic level, an Action corresponds to a similarly named function defined within the Feature file on which the action is being defined. So, for example, if you define an Action called start on a feature called virtual_machine, you will find that a function named start has been created within the feature file named virtual_machine.py. On the functional level, an Action will typically correspond to an operation on the cloud resource corresponding to the containing feature. E.g. start action defined within the feature virtual_machine will most likely correspond to the Start operation on a Virtual Machine on the target cloud(s)/hypervisor(s).

The following schematic diagram represents a very high level and grossly watered down view of the overall architecture of the xPlore.Cloud solution.


To get a high level account of how xPlore.Cloud works, you can visit a blog post here .