preface statement: manageing OpenStack & SoftLayer resource with Jumpgate

1,forward;

Imagine a world of interconnected Clouds capable discovering, coordinating and collaborating in harmony to seamlessly carry out complex workloads in a transparent manner -- the intercloud . While this may be the dream of tomorrow, today‘s reality is a form of the intercloud called hybrid Cloud . In a hybrid Cloud model organizations manage a number of on-premise resources, but also use off-premise provider services or resources for specific capabilities, in time of excess demand which cannot be fulfilled via on-premise resources, or for cost effectiveness reasons. Both of these Cloud computing models have a common conduit to their realization -- open standardized APIs, formats and protocols which enable interoperability between disparate Cloud deployments.

Enter OpenStack -- a rapidly growing open source Cloud framework which removes vendor lock-in by providing open, vendor agnostic APIs. OpenStack consists of a number of distributed, scale-out ready services which allow organizations to build Cloud solutions in a more cost effective manner. Just as the name implies OpenStack is open source, open design and open teaming / leadership. As shown in a  2013 Forrester study , collectively OpenStack becoming the most popular private Cloud of choice (see diagram below).

SoftLayer is the premier Data Center and hosting provider in the industry today offering numerous pre-built managed services and solutions to fit many needs -- from web hosting to private hosted Clouds -- SoftLayer is the right choice. Not only does SoftLayer provide soft services, but they also offer fully dedicated bare metal hardware suitable for the most demanding workloads. SoftLayer also supports a comprehensive set of native APIs allowing developers and operators to take programmatic control over their resources. Wouldn‘t it be great if you could use OpenStack APIs with SoftLayer? As luck would you have it, you now can.

The folks over at the SoftLayer innovation team recently released a new open source project called Jumpgate . With Jumpgate you can use a number of your favorite OpenStack tools and APIs to bridge directly into SoftLayer. For example you can use the OpenStack nova CLI and APIs to boot SoftLayer virtual compute servers, or the OpenStack glance CLI to manage SoftLayer based images. You can even use the OpenStack Horizon dashboard to graphically manage a number of your SoftLayer resources including virtual servers and images.

In this article we‘ll cover the following topics:

• An overview of Jumpgate including its high level architecture.
• Step-by-step instructions on how to install and configure Jumpgate including creating an upstart job to manage Jumpgate as a service.
• Detailed instructions on how to install and use the OpenStack nova CLI with Jumpgate.
• A guide to setting up the OpenStack Horizon web-based dashboard with multiple regions so that you can manage SoftLayer resources from a single pane of glass.

2,Introducing softLayer Jumpgate

Jumpgate is an open source project started by the folks over at SoftLayer innovation labs which aims to bridge the gap between OpenStack native APIs and other proprietary vendor APIs -- an API adapter proxy if you will. Jumpgate is implemented in the Python programming language as a WSGI application and thus runs as a web based service.  As a fully compliant python WSGI application, Jumpgate can be hosted via a Python server such as  gunicorn or fronted by your favorite web server with WSGI support such as Apache with mod WSGI or nginx with NgxWSGIModule . 

From an architectural perspective Jumpgate is stateless (no persistence) and lightweight making it easy to scale out suiting the needs of many deployment scenarios. Under the covers Jumpgate is pluggable, allowing you to easily snap-in or snap-out both request and response middleware "hooks" and service drivers.

Jumpgate request and response hooks permit you to write and plug-in Python code which can work with requests and responses as they enter / leave the Jumpgate application. For example you could easily implement a hook to support API rate limiting or fully featured request auditing. Out of the box Jumpgate includes a number of pre-built hooks including logging and authentication.

Jumpgate service drivers provide the functionality needed to translate OpenStack native API requests into native APIs requests and back again as OpenStack compliant responses. Think of these drivers as adapters. These drivers are pluggable per OpenStack service endpoint supported by Jumpgate -- image, compute, network, identity, etc..  Out of the box Jumpgate provides a set of SoftLayer drivers which allow you use a number of OpenStack client side tools immediately with SoftLayer Jumpgate. It‘s also possible to implement and snap-in your own drivers to support bridging between OpenStack APIs and your native API.

From and identity perspective, Jumpgate also includes a number of other plug points providing maximum flexibility for your solution needs. For example the Keystone compliant service catalog served by Jumpgate is based on a template file which look much like the Keystone default catalog . These endpoints can be modified to suit your needs and you can also plug in other remote service endpoints you wish Jumpgate to expose in the service catalog. Jumpgate also includes pluggable token and authentication drivers allowing you to control how authentication requests are fulfilled, as well as how tokens are structured, encoded and decoded.

The diagram below depicts the high level architecture of Jumpgate. On the left side of the diagram the generic form of Jumpgate is illustrated whereas on the right the SoftLayer specific drivers which realize the bridge are shown. You can also check out Nathan Beittenmiller‘s SoftLayer blog on Jumpgate .

From a development perspective, Jumpgate is a young active project which is growing / enhanced daily. As such, not each and every OpenStack API is supported with the out of the box SoftLayer drivers today. Instead, the most common OpenStack APIs were selected and initially implemented with additional APIs being added incrementally until the bridge is sufficiently supported. For a more complete list of the APIs supported, see the "compatibility matrix" on the Jumpgate developers page . That being said, please do file issues if you run into any bugs or if you have feature requests. Moreover, we are always looking for contributions so if you are feeling Pythonic please help out by following the contributors guide .

Let‘s now move to the hands-on instructions and get Jumpgate running.

3,Installing & Setting up Jumpgate

For this guide we‘ll be setting up Jumpgate and related components on a SoftLayer Cloud Computing Instance (CCI) which is running the Ubunutu 12.04 Operating System. However, you could just as easily provision Jumpgate off-premise SoftLayer as the SoftLayer API (SLAPI) endpoint is public facing and reachable over the public network. Moreover a number of the exact commands shown here are Ubuntu specific (i.e. apt-get , initctl , etc.), but they can easily be translated into your distro of choice.

In the steps that follow I will provide snippets from my terminal which include my shell prompt, followed by the exact command(s) run. I will also show an abbreviated section of the command‘s output using " ... " to indicate additional output is removed for brevity. I tend run multiple commands on a single line using the bash && operator. This operator can be used to chain multiple commands on a single line and indicates bash should execute the commands left-to-right, one-by-one only running subsequent commands in the chain if the previous executes successfully. If a command should fail, you can address the failure and run the remaining commands one-by-one. Finally I‘m performing all steps in this guide as a non-root user and thus use sudo to execute commands as root.

Before you begin

In order to prepare for the Jumpgate installation and setup, take a moment to consider the topology you wish to realize with this solution. In particular consider the following questions:

• Will the components consuming Jumpgate be located on the same host as Jumpgate, or will they be remote?
• If the components consuming Jumpgate are remote, which IP / interface will they be using to communicate with Jumpgate?
• Which port will Jumpgate bind to on your host system? If you are planning to run OpenStack Keystone on the same system using Keystone‘s default ports, you will need to select a different open port for Jumpgate to bind on.

As a result of the questions above, you will need to determine the IP address Jumpgate will bind and listen on. If your solution will always have the Jumpgate consumers on the same host, you may choose to bind Jumpgate to the loopback IP of your host (localhost, 127.0.0.1) and thus not expose it externally. However if your Jumpgate consumers will be remote, you may want to restrict their access to the private IP of your host in which case Jumpgate would bind to the private IP / network.

The IP address you wish to bind Jumpgate on is referred to as the JUMPGATE_IP in the instructions below. Any place you see JUMPGATE_IP , substitute the IP Jumpgate will bind to.

Likewise the port you will bind Jumpgate to is referred to as JUMPGATE_PORT below. Substitute your selected Jumpgate bind port accordingly.

Install Prerequisites

The first thing we need to do is to install some prerequisites (dependencies) needed by Jumpgate and it‘s python requirements. Note that NTP is not required by Jumpgate, but my preference is to keep server times in sync and thus I illustrate its setup here.

jumpGate部署