Openstack deployment options

Openstack wants to be as flexible as possible. It means that each service that is developed under the umbrella of Openstack has to be written in a modular way to accept different backend system depending on user preferences. From a high level point of view it means that a service need to have a well defined internal and external API, and the more specific technical implementation details are left for backend systems.

The Openstack specific public (external) API is one milestone for every project. If the API is not reach, flexible and useful enough it will not empower uses when consuming the service. On the other side, if the internal service level API is badly design it may cause issues for example when integrating with other components, exchanging messages, causing bottlenecks or hinder vertical scalability to expand system capacity.

Below is a list of deployment options for Folsom and Grizzly Openstack release.

• External API
•  XML
•  JSON

• Possible hypervisors for OpenStack Compute
• KVM
• Xen
• Citrix XenServer
• Microsoft HyperV
• VMware ESX
• LXC

• Possible OpenStack Block Storage drivers 
• Coraid
• EMC
• GlusterFS
• Huawei
• LVM
• NetApp
• Nexenta
• NFS
• Ceph RBD
• SAN/HP
• SAN/Solaris
• Scality
• Sheepdog
• SolidFire
• Storwize
• Windows
• Xenapi
• XIV
• Zadara

• Possible OpenStack Network backends 
• Big Switch
• Brocade
• Cisco
• Hyper-V
• Linux Bridge
• MidoNet
• NEC
• Nicira
• Open vSwitch
• PLUMgrid
• Ryu

• OpenStack Identity drivers
• LDAP
• SQL
• PAM
• KVS