OpenStack public cloud by HP & RackSpace

OpenStack community is an open source community focus on providing cloud computing platform. It started in 2010 as a joint project of NASA and RackSpace based on work done in NASA and quickly gain traction with over 150 additional companies joining the community.

OpenStack is used internally in companies experimenting and using private clouds as well as by IaaS providers who use it for their public cloud platform.

As part of the joint work I have been doing with GigaSpaces, I had the chance to experiment with two of the larger companies providing OpenStack driven IaaS – HP & RackSpace.

From prior experience with Amazon EC2, one of the first things that is quite obvious when you start experimenting with the HP & RackSpace platforms is that the UI is quite minimalistic. In addition, these platform aren’t as feature rich as Amazon AWS is, in some case, requiring the user the be more knowledgable with system administration to complete similar tasks (such as creating an SSH authentication key or configuring the server firewall).

In part, this seems as a different approach and different exceptions from the users. However, part of it should be attributed to the maturity of the platform and the depth of integration with this new platform these provider were able to achieve in a short amount of time. I am sure that in this area, we will see quite a few new features in the months to come.

Having dealt with the OpenStack RESTful API of both providers, you may expect to utilize the same code for both by just changing the credentials and endpoint configuration attributes.

Well, reality is a bit different… The API very close to each other, but they are not identical. Most of the client access code can stay the same, but the some differences are there…

Maybe the most significant difference is in the Keystone authentication which in HP case, uses element apiAccessKeyCredentials that contains the accessKey and secretKey (they also have a user/password option). In Rackspace case, they have a special element RAX-KSKEY:apiKeyCredentials that contains username and apiKey (this is an extension RackSpace added to to the API (Not sure why…).

HP authentication request:

curl     -X POST -H “Content-Type: application/json” \
     https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/tokens  \
    -d ‘{“auth”:{“apiAccessKeyCredentials”:{“accessKey”:”xxxxxxxxxxxxx”,”secretKey”:”xxxxxxxxxxxxxxxxxx”}}}’
 

RackSpace authentication request:

curl -X POST -H “Content-type: application/json” \            
      https://auth.api.rackspacecloud.com/v2.0/tokens \ 
     -d ‘{ “auth”:{ “RAX-KSKEY:apiKeyCredentials”: {“username”:”xxxxxxxxxxxx”,”apiKey”:”xxxxxxxxxxxxxxxxxxxxxx” }}}’ 
 

There are a few more nuances such as image and flavor Ids vs. image and flavor ref in creating a server instance.

HP create server request:

curl -i \
-H “X-Auth-Token: 1847d195e424f979a65214ae8bd6e955d87cfad4” -H “Content-Type: application/json” \
https://az-1.region-a.geo-1.compute.hpcloudsvc.com/v1.1/######/servers \
-X POST -d ‘{“server”: {“name” : “Test”,”imageRef”:”417″, “flavorRef”: “100”}}’
 

RackSpace create server request:

curl -i \
-H “X-Auth-Token: 1847d195e424f979a65214ae8bd6e955d87cfad4” -H “Content-Type: application/json” \
     https://servers.api.rackspacecloud.com/v1.0/######/servers  
    -X POST -d ‘{“server” : {“name” : “new-server-test”,”imageId” : 1,”flavorId” : 1}}}’
 

Another aspect that need to be taken to account is different defaults and behavior choices. One example is a public IP for a new server. In HP, the instance is created without a public IP and you can associate a public IP with the server after it is created. In Rackspace, the server is created with a public IP.

HP approach is quite logical and let you choose which server to open out to the Internet, but it makes your life a little more difficult when you want to create a server that will be accessed publicly.

Utilizing a tool such as Cloudify or Chef, will save you the need to be aware of these things that for most users are nuisances. In Cloudify, you have the concept of Cloud Driver that abstracts the vendor specific cloud API from the rest of cloudify. You get most of the common clouds supported out of the box and you can write a new or extend an existing Cloud driver to support additional clouds.

BTW, Cloud Drivers are excellent example of code that once was written can be share with the community.

HP and Rackspace are offering an alternative to the Amazon dominance in the public clouds space with an approach that embrace OpenStack open source platform for public as well as private clouds. It offers enterprise a path to the modern cloud infrastructure while still allowing them to move between vendors as well as between public, private and hybrid cloud approaches.

Amazon, the clear market leader, is aware of this and its first defensive move is to partner with Eucalyptus to provide a similar public/private approach, but still with a vendor/API lock-in.

An interesting analogy to the Amazon EC2 vs Openstack is to the Linux vs.  Windows 10-15 years ago. Windows was more feature rich and was much easier to use, Linux on the other hand was open and enjoyed a rapidly growing community of supporters.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s