An Approach to enabling Hybrid Cloud for enterprises using OpenStack API-Proxy Server and third party solutions.

1. 1
OpenStack Federated Cloud Services using API-Proxy and third party solutions
Dinkar Sitaram, Sudheendra Harwalkar and Shreyas M M from PES University, Bangalore – India
There is a global shift towards enabling Hybrid Cloud for enterprises; many solutions already available or work in
progress from Service Provides
and Open Source Communities,
but not many approaches from
the enterprise point of view. We
are working to provide a solution
with OpenStack as a focal point.
In our approach (refer Figure 1),
we develop API Proxy server to
intercept request / response for
federation and make use of
OpenStack Availability Zone,
Keystone Federation and
experimental WSGI scripts
provided by the community. Our
solution doesn’t modify any of the
core components or update the
database.
So far we are able list, create and delete for compute, storage (including image) and network related services from
multiple OpenStack clouds, though we have encountered few issues with network. Also to some extent were
successful with heat Autoscale (in the remote cloud), and currently working on enabling ceilometer to monitor the
VMs created by heat autoscale in the remote cloud(s). Our setup had multiple multi-node OpenStack (Newton).
OpenStack API components needs be started from behind Apache web server, by creating virtual hosts using
respective component
ports ( by default Nova
Services uses port
8774), as shown in
Figure 2: sample
virtual host
configuration file,
WSGIScriptAlias should
pointing to the
absolute path of script
file. Similarly, need to
add/create virtual
hosts for other
components like
Neutron (Network),
Glance (Image), Cinder
(Block Storage).
Figure 1 : Federated Cloud Services - Architecture
Figure 2: Virtual host configuration file

2. 2
Figure 3 is a Skelton Middleware code for Intercepting the request and Check for request method
(POST/GET/DELETE/UPDATE) and checking for Availability Zone in POST request.
If it’s Pseudo AZ, initiate request to remote cloud (refer Figure 4) by getting federated scoped token (refer code
snippet Figure 5).
Figure 3: Middleware for Request/Response interception
Figure 4: Request to Remote Cloud

3. 3
Our experiments had four multi-node OpenStack clouds (Newton release) on Ubuntu 16.04LTS, with keystone
federation and using Keystone as an Identify provider.
While configuring keystone federation, it’s necessary to setup Service provider ID as <REMOTE SERVER HOST
ADDRESS>, however provision has been made to be configurable. And Identity provider (idp) details (like
IDP_USER_ID, IDP_AUTH_URL, IDP_PROJECT_ID, IDP_PASSWORD and etc.,) are configurable and are part of
OpenStack components configuration files
Pseudo Availability zones were created by setting up Nova-compute/Cinder/Neutron running in LXC containers;
Name of the pseudo availability zone needs to be in the following format
<REMOTE SERVER HOST ADDRESS>: <REMOTE AZ>
Benefits:
1. Federated Cloud Services framework doesn’t duplicate or modify any of the current component
functionalities; including client component (dashboard/CLI) and also it can be deployed or removed easily
without affecting the independent cloud functionalities.
2. Federated Cloud Services framework enables accessing of the resources across the clouds using GUI
(Horizon), CLI or using orchestration (Heat) and Telemetry (ceilometers) components without any
modifications to existing API interface and its functionalities.
3. There is very minimal response delay during the configuration due to accessing of remote resources by
using federated token, however no affect on overall system performance from user point of view.
Figure 5: Federated Token Code Snippet

4. 4
Drawbacks:
1. As the requests and response from core components are not uniform across, one may end up in writing
more code for few specific scenarios.
2. Requires additional (commercial?) third part product/plug-in to enable non OpenStack public clouds.
ASKs to the community:
1. Is it possible to include Availability Zone (AZ) in all the requests, currently it’s only in POST Requests,
correct us if we wrong. AZ inclusion will helps us in request routing and can avoid mapping of resource
name and ID on the fly for every request, to make it visible to clients (Horizon/CLI).
2. In federated environment, we may have multiple Provider Network, is this practically feasible? Any
suggestions how we can discover, we use Availability Zone to discover Compute and Storage resources
and is it possible to provide similar functionality in Network (Neutron) from the user perspective.
3. Creation of Flavor needs admin privileges; however in the federated environment it may not be feasible
to get admin privileges from remote cloud(s), is it possible to enable creation of flavor by any non admin
users.
4. When we start Image (Glance) API service under Apache server using WSGI script, we observe listing
works fine, however creation of new image not working, it stays in the queue, recent review update in
github mentions that everything is working fine.
5. Request for Enabling creation of (Pseudo) Availability zone in Horizon and CLI without any nodes
(Compute, Storage and Network), compute has option to create, but it’s not visible till we attach a node.
6. Any plans to port OpenStack onto AWS, Azure and other non OpenStack public clouds, we are aware of
third party solutions (included in Figure 1).
References:
1. Openstack Architecture from http://netapp.github.io/openstack-deploy-ops-guide/juno/content/section_modular-collection.html
2. OpenStack Newton Installation from http://docs.openstack.org/newton/install-guide-ubuntu
3. Keystone Federation from http://docs.openstack.org/developer/keystone/federation/federated_identity.html
4. Nova experimental WSGI script from https://github.com/openstack/nova/blob/master/nova/wsgi/nova-api.py
5. Writing Middleware from http://helpful.knobs-dials.com/index.php/General_WSGI_notes
6. OpenStack on AWS from https://www.ravellosystems.com
7. OpenStack on Azure from http://www.outworx.com
8. OpenStack on VMware from http://www.vmware.com/products/openstack.html
Acknowledgment:
We thank PES University for providing development and test environment setup at Cloud Computing and Big Data
Center (CCBD) at PES University, Bangalore.