OpenStack Federated Cloud Services using API ...

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. Figure 1 : Federated Cloud Services - Architecture 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 2: Virtual host configuration file

1

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.

Figure 3: Middleware for Request/Response interception

If it’s Pseudo AZ, initiate request to remote cloud (refer Figure 4) by getting federated scoped token (refer code snippet Figure 5).

Figure 4: Request to Remote Cloud

2

Figure 5: Federated Token Code Snippet

Our experiments had four multi-node OpenStack clouds (Newton release) on Ubuntu 16.04LTS, with keystone federation and using Keystone as an Identity provider. While configuring keystone federation, it’s necessary to setup Service provider ID as , 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 : 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.

3

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 are 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. 2. 3. 4. 5. 6. 7. 8.

Openstack Architecture from http://netapp.github.io/openstack-deploy-ops-guide/juno/content/section_modular-collection.html OpenStack Newton Installation from http://docs.openstack.org/newton/install-guide-ubuntu Keystone Federation from http://docs.openstack.org/developer/keystone/federation/federated_identity.html Nova experimental WSGI script from https://github.com/openstack/nova/blob/master/nova/wsgi/nova-api.py Writing Middleware from http://helpful.knobs-dials.com/index.php/General_WSGI_notes OpenStack on AWS from https://www.ravellosystems.com OpenStack on Azure from http://www.outworx.com 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.

4