Having a lark at PARC! - Cloudsoft

A fortnight after successfully integrating with Abiquo, we had the opportunity to visit the legendary Xerox Palo Alto Research Center (better known as PARC) to see if we could work our magic on their Nebula ONE powered private cloud.

Built by Surendra Reddy and his team, PARC’s private cloud has already hit the headlines in Business Week so we were curious to see how easy it would be to integrate with this.  As we well know by now, there are usually some bumps to be expected when meeting a new cloud API.

After some intros, in particular to Roger Hoover, we jokingly asked “PowerPoint or Eclipse?” and Surendra fired back with “What about NetBeans or Intelli-J?”, which answered the real question in the affirmative: it was going to be a coding session.

As PARC operates a strict security policy and we only had access to their guest network, Roger drove, starting with a straightforward:

git clone https://github.com/brooklyncentral/brooklyn.git
cd brooklyn
mvn clean install

While that ran, we created ~/.brooklyn/brooklyn.properties (and went for coffee):


Re-upped with caffeine, we were ready to come back and fly through the inevitable clear air turbulence! We started with the simplest example.

cd examples/simple-web-cluster
mvn assembly:assembly
rm -rf /tmp/brooklyn-parc-catalog-0.1.0-SNAPSHOT
tar -x -C /tmp -f target/brooklyn-example-simple-web-cluster-0.6.0-SNAPSHOT-bin.tar.gz
pushd /tmp/brooklyn-example-simple-web-cluster-0.6.0-SNAPSHOT

It was clear right away that we’d gotten something wrong. We tried various other endpoints and settings, even Nebula’s EC2 bridge API endpoint, before we came back to a couple obvious (but always forgotten) points – we needed to specify a tenant and set the provider to openstack-nova, and so on.

The magic properties were:


And we were logged in; it auto-detected a nice looking image and a nice big flavour, and then bam — everyone’s favourite “request limit exceeded”. The request limit is very low on OpenStack by default. A quick fix in this case is to specify both the key pair and the security group Brooklyn uses (or you can tune the frequency used by Brooklyn, or see about getting a higher request limit).

We also hit a similar VM name length limit as we did with Abiquo, and used the same solution. There was ample capacity here, so we went for a beefy machine, and we opted to use a specific preferred base image. The new properties were:


And it created the VM, we wait, we wait, then fail. The error message shows it couldn’t reach the machine via ssh. The logs showed that in fact the VM booted in well under a minute. “Of course,” Roger said, “it runs in its own private subnet.”

We went for lunch and schemed. We could deploy brooklyn to the same subnet. Or we could create floating IP’s or VPN’s. The latter seemed like a couple hours’ work however, whereas the former is just a couple minutes. But when we returned from lunch we had an email telling us to look at JcloudsLocationConfig.AUTO_CREATE_FLOATING_IPS.

One more line in our brooklyn.properties file would do the trick, the email alleged:


Result! A VM we could log in to. Pretty soon we had JBoss and nginx installing and our simple web cluster done and dusted. On a roll we soon had Cloudera (our stock smoke test for any cloud) deployed and running.


Non-plussed, the PARC team wanted more and Roger raised their first issue – in this case Storm. Sensible given our support for Kafka.

. . .
One purpose of these blog posts is to let people know the problems we hit in the field and how we solved them (so you don’t have to!). Here, it was a Nebula ONE cloud, an API species we’d never yet shaken hands with: but we’re glad we did! Hats off to Chris Kemp and the guys at Nebula who’ve created one of the most responsive private clouds we’ve seen.

As we’ve said in the past Thank God we chose to go to the Moon. A little closer to home we can now say “Thank goodness NASA & RackSpace decided to create OpenStack!” :-)