Category Archives: openstack

I got a comment on my jclouds and OpenStack post about how to get the Tenant ID via jclouds. The first solution that popped to my mind was to get the Tenant ID out of the access data structure that gets returned upon authentication. This turned out to be a bit trickier than expected as jclouds automatically authenticates on your first actual interaction with a cloud (i.e. the very first time you call a method that needs to talk to the cloud). To get the access data structure I needed to manually authenticate. Here’s how to do it.

Get jclouds

First off, get the jclouds JAR files.

1. Ensure you are using the Java Development Kit (JDK) version 6 or later.
   • javac -version
2. Ensure you are using Maven version 3 or later.
   • mvn -version
3. Create a directory to try out jclouds.
   • mkdir jclouds
   • cd jclouds
4. Make a local copy of this pom.xml file in the jclouds directory.
   • mvn dependency:copy-dependencies "-DoutputDirectory=./lib"
5. You should now have a directory with the following structure:
   • jclouds/
     • pom.xml
     • lib/
       • *.jar

Manual Authentication

Put this code in your jclouds directory to do manual authentication. An explanation follows.

1. Compile.
   1. javac -cp ".:lib/*" JCloudsManualAuthentication.java
2. Run on OpenStack.
   1. java -cp ".:lib/*" JCloudsManualAuthentication openstack-nova demo:demo devstack http://123.123.123.123:5000/v2.0/
3. Run on Rackspace as this code works equally well with any OpenStack powered provider.
   1. java -cp ".:lib/*" JCloudsManualAuthentication rackspace-cloudservers-us myRackspaceUsername myRackspaceAPIKey

The key to the example is lines 93 & 94. Because jclouds normally handles the authentication manually we have to use a bit of Guice-fu on line 93 to get a hold of the Function that can manually authenticate by taking our Credentials and returning the Access data structure. On line 94 we execute that Function and the authentication happens. After that we can run through the Access object and get the information we need.

Coda

It’s rare that you would need to authenticate manually in jclouds. Most of the time letting jclouds automatically handle the auth for you suffices. However, if you do need to authenticate manually, this method will give you a lot of information about your OpenStack environment.

Cross-origin resource sharing (CORS) is a mechanism that allows Javascript on a web page to make XMLHttpRequests to another domain, not the domain the Javascript originated from. Such “cross-domain” requests would otherwise be forbidden by web browsers, per the same origin security policy. CORS defines a way in which the browser and the server can interact to determine whether or not to allow the cross-origin request. It is more powerful than only allowing same-origin requests, but it is more secure than simply allowing all such cross-origin requests. [1]

In the context of OpenStack Swift and Rackspace Cloud Files a CORS enabled container allow users to upload files from one website–or origin–to your Swift/Cloud Files container. When you set the CORS headers on your container, you tell it which sites may post to your account, how often your container checks its allowed sites list, and whether or not metadata headers can be passed with the objects.

You can find example code to enable and configure CORS at CrossOriginResourceSharingContainer.java. To allow users temporary access to a such a container you would use example code like GenerateTempURL.java.

[1]
http://en.wikipedia.org/wiki/Cross-origin_resource_sharing

The OpenStack Grizzly Summit has wrapped up and it was another huge success. The new format of having the Summit and Conference at the same time worked well. Good venue, the wifi held up, the organizers accommodated the overflow people (i.e. 200-300 unregistered attendees) with amazing aplomb, there were always healthy food choices, and coffee/water was present at all times. All in all, great organization by the OpenStack Foundation that allowed everyone to stay focused on the task at hand, improving OpenStack in every way possible.

I wanted to highlight some of the progress made on the Software Development Kit (SDK) front during the Summit.

Monday

I led a session titled SDK Documentation Discussion (here are the raw etherpad notes). I’ve been participating in Summits since Bexar in San Antonio and, as far as I know, this is the first time SDKs have been discussed in any depth so it turned out to be more of a survey of existing SDKs and brainstorming session. We started with a definition of SDKs to make sure we were all on the same page. I asked what SDKs people were using and got a variety of answers. On the topic of what criteria to use to allow an SDK to claim OpenStack support we thought that one day the Foundation might have some sort of validation test suite to determine compatibility.

Finally getting around to the topic of documentation, we brainstormed some ideas for documenting method level APIs in an SDK native doc tool while still keeping that information consistent with existing OpenStack specs. We also talked about a number of ways to keep up to date with changes to the various APIs. I think I can summarize that as simply having to tune my receptors to all the different channels where API change notifications can be broadcast. When the question of what it means for an SDK to be considered feature complete came up, I was somewhat surprised to hear the opinion that documenting your feature support can be more important the “feature-completeness”. Upon a bit of reflection, this makes good pragmatic sense. As a developer many times all I want to know is if this tool is going to do what I want it to without having to get a developer environment setup and prototype something.

I’ve been purposefully a bit vague in my descriptions above because one of the action items to come out of the discussion was for me to start tracking this stuff on an OpenStack wiki page and I didn’t want to duplicate the information here. You can now find that page at wiki.openstack.org/SDKs.

Tuesday

On Tuesday I spoke to Simon Anderson, CEO of DreamHost, and explained how Rackspace was committing developers to support open source cross-cloud toolkits such as jclouds, libcloud, fog, and php-opencloud. I talked about how HP is also supporting Java jclouds and Dell is supporting Ruby fog. How if we all throw our weight behind select SDKs, the quality and support of those SDKs will be better and we can avoid fragmentation. Plus we’ll inherit all of the existing OpenStack support, documentation, sample code, and user bases in those projects. Simon perceived the benefits immediately and let me know his team at DreamHost would start looking at supporting those toolkits as well.

The DreamHost team are a great group of people and I’m really looking forward to any future collaborations.

Wednesday

Wednesday started out with the Rackspace media team releasing the video A Look at SDKs.

Troy Toman from Rackspace gave a morning keynote. Personally I found it quite inspiring. He described how Rackspace runs on OpenStack trunk minus 2 weeks. We’ve got Grizzly already! Troy showed how we can have a build of OpenStack ready to go in 47 minutes and prepared for production. He also talked about how Rackspace engineers will turn their attention back to the community now that we’ve got OpenStack in production. We’re committed to trusting the community. It was also very generous of Troy to highlight our SDKs and give the Developer Relations Group a shout out.

A design session titled Standardizing client & API capabilities (here are the raw etherpad notes) led by Gabriel Hurley I found to be very relevant to SDKs as well. He was proposing an effort to achieve consistency and common feature (e.g. pagination, filtering, bulk objects action, etc.) parity across the various APIs as well. In all of the subsequent API design sessions I attended I was sure to bring up Gabriel’s effort and in the hopes that all of the API design efforts underway would take his proposals into consideration sooner rather than later. If OpenStack can deliver a more consistent API experience, it will drastically simplify writing SDKs and provider a better overall developer experience.

Thursday

On Thursday I gave my Control the Clouds: Developer Experience with jclouds workshop. You can find the workshop itself at bit.ly/jclwork. Considering it was in the second last time slot session of the entire Summit, there was a relatively good turn out of 20-25 people. The workshop went off without any network problems (thanks Cisco) or Murphy’s Law style issues, which was a relief. I got some good questions at the end so I knew people were engaged.

By this point in the Summit the tech press were well aware of the new Rackspace open cloud SDKsthanks to the masterful efforts of Wayne Walls and Hart Hoover. They got the SDKs mentioned in the following articles.

• Rackspace Opens SDKs for Java and PHP
• Rackspace Launches Open PHP, Java SDKs for OpenStack
• Rackspace Creates SDKs for Java, PHP
• OpenStack Summit: Open Cloud Platform Gets Big Push
• Rackspace Gives Java and PHP Developers Power to Leverage OpenStack Services

Coda

A lot of hard work and preparation went into getting ready for this Summit. Everything went amazingly well and it exceeded my expectations in practically every way possible. Cheers to the OpenStack Foundation for putting on such a well organized event. No doubt the Grizzly release will live up to its namesake.