As the platform matures, we see many cool applications being built on top of Cloud Foundry. This is the first in a series of guest blog posts by application developers explaining what their application does, how it is architected, what they like in Cloud Foundry and what needs to be improved.

Guest blog post by Eric Bottard

ThemaTweets2012 allows you to visualize what people say about the french elections candidates on Twitter, how these candidates relate to key themes of this 2012 event and analyze information under several angles.

The Story

In late 2011, Google France launched a data visualization challenge about the upcoming 2012 presidential elections. The rules of the challenge were pretty straightforward : provide a web application that leverages data from Google and/or Twitter and shed a new light on the french elections. The winners would eventually win a trip to Mountain View, or a nice Android tablet.

My team and I started hacking pretty late and although we wanted to use that opportunity to experiment with new technologies and great ideas (after all, the main reason we engaged in the challenge was for the fun of it), we focused ourselves on one simple thing : detecting the topics that mattered the most to people, and how candidates to the elections related to those. Now, you’ll admit that 140 characters is not much to convey structured information. Add to this the fact that people don’t always put a lot of effort into writing elaborate sentences on Twitter, so we decided to keep things simple : we would only count occurrences of candidates and topics, without trying to analyze the tone of the tweet.

Being a dataviz oriented application, ThemaTweets allows the user to navigate between different views of the same raw data. The main screen shows an overall breakdown of candidates and then the topics mentioned in tweets (eg. Nicolas Sarkozy is found in 43% of the tweets we captured and amongst those, 28% cite the topic “Taxes”). Click on a button and you’ll invert the view (eg. 54% of tweets captured deal with “Ecology”, of which 33% are linked to François Hollande).

One can also view the evolution of these figures over time. This is already useful and interesting, but we wanted to go further than that and help some hidden information surface out of those simple datapoints. So the application also has two other views :

1. one allows us to see how topics “belong” to a political side. By assigning some kind of left-right alignment to each of the candidates, we can average the relative positions of topics relative to each other.
2. the other selects the topics that are the most often encountered for each candidate and then displays the “overlap” that one can find between two (or more) candidates. For example, if N. Sarkozy is linked to “Euro crisis” in 34% of the tweets and Dominique de Villepin is credited with 21% of tweets for the same topic, we’d link them together with an arc. The thickness of the arc at both ends reflects the percentages.

Lastly, we added a view that highlights the terms we captured in the tweets, so that people can witness were the data is coming from.

Of course, users can view the evolution of topics or candidates share over time

How the application actually works

Under the hood, ThemaTweets is a simple web application, built on top of Spring and Hibernate. The data model is rather simple, with an added twist whereby we aggregate data hourly to avoid recomputing means and sums every time a view is needed. It leverages the twitter4j library to connect to twitter, making use of the streaming API. There are fixed keyword terms made of the candidates names (and their political parties, collaborators and so on). This allows the twitter API to pre-filter results. Then, for each tweet that is received, the app tries to match it against keywords related to topics. Contrary to the candidate filter, there is an opportunity here to apply Lucene related technology where we tokenize and stem the words (so that we would match “écologie”, “écolo”, “écologiste” as well as variants without the accented “é”). While we originally went for a trained bayesian filter approach, the ratio of useful words to garbage was really huge. So we decided to keep the algorithm, but using only handcrafted positive weighs for the topic words. This worked really well.

Terms that are captured in tweets are highlighted and linked to views in the application, so that users understand where the data is coming from

Being proficient with the technologies used helped us prototype quickly, with an added productivity bonus coming from Spring Data JPA. The application UI is really client centric, with data coming in JSON from Spring MVC controllers.

Interacting with Cloud Foundry

We chose from the start to experiment with some cloud infrastructure, just for the fun of it. Moreover, we had no idea of the exposure the app would get once the challengers would be revealed. Sadly, we did not have time to lose trying to bend our minds around limitations in JPA queries that actually operate on a NoSQL backend, or trying to have maven and a cloud related eclipse plugin play nicely together. So we finally went for Cloud Foundry after one or two days.

The setup was the most impressive experience I guess. Imagine adding 3 lines of maven plugin configuration to your pom.xml and being able to push the application code directly to the cloud ! The interaction with the vmc command line tool was also very pleasant, and provisioning services by simply following a wizard felt refreshing.

I think the most astonishing feature was the fact that, ThemaTweets being a rather simple app with only one datasource, it got reconfigured automagically to use the cloud mysql instance, as detailed here. So the very same code that ran locally could be deployed in the cloud with no modification.

Also, having access to a genuine java virtual machine without restrictions also was decisive in our choice. Indeed, the Twitter streaming API requires a long lived thread to be connected to the twitter servers, which ruled out some of the alternatives.

Those three lines of XML configuration are all that is needed to deploy to the cloud with maven

Of course, there were some difficulties nevertheless. The biggest drawback comes from the fact that when you’re in the cloud, you’re pretty blind to what happens with your app. At first, there was no way to know what was getting stored in our database, so we had to roll out our own back office application. Luckily, the tunnel solution was discovered soon after, although we had a very hard time making it work on a mac (something that should go more smoothly in the future if I understand correctly).

A side effect of this blindness is that importing / exporting data is pretty complicated, even with the tunnel working. Because of timeouts that have to be enforced on the mysql services, exporting our data had to be done in chunks, which was a bit tedious. Nevertheless, I believe the tunneling approach is very smart and could allow other usages in the future.

We also witnessed some strange memory usage from time to time, whereas the app was behaving very nicely locally.

Some additions to the platform could also be considered as “nice to have”, even though we made it without them. For starters, code versionning was not really an issue for us, as the app was not live until the challenge was over. But because Cloud Foundry allows services to be bound to multiple applications, I guess you can get away with having another app alias running the new code and being bound to the same services.

We also needed our Twitter connector to be a singleton among the whole cluster. While we ended up starting it from an http thread, having a cloud-aware singleton spring scope supported by the platform would be nice (remember that you can’t know beforehand the IP addresses of the machines you’ll be running on, etc.)

I also recently realized that although Cloud Foundry almost gives access to a vanilla Tomcat server, there is no way to add custom jars to the lib/ folder (eg. to allow Spring load time weaving). The platform does add the mysql/postgresql jdbc connector jar for you though.

Finally, I guess what the platform today lacks compared to the competition is a nice looking web UI, although the vmc command line tool (and the REST API behind it) offer a lot information.

Happy End

As you can guess, we were really impressed by the technology. We did not win the first prize in the challenge, but made it to the finals nevertheless. For the purpose of being shown on this youtube channel, the app had to be moved and operated by Google. Because Cloud Foundry did not force us to modify our plain Spring MVC app, the very same war file is now hosted on another platform and it works like a charm.

Signup for Cloud Foundry today, and start building your own cool app!

Here’s our monthly newsletter with the main news from the last month, including what you can expect in the coming months.

Technology

Of course, the big news this month was the launch of OpenNebula 3.2, with lots of new features like:

• VMware, out-of-the-box support for VMware that now includes live migration, advanced contextualization, image and network management.
• Self-Service Portal, a new easy-to-use web-based end-user interface that complements the existing GUIs for the operation of the data-center (OpenNebula Sunstone) and for the management of multiple zones (OpenNebula Zones). You can see a couple screenshots of this new interface in this blog post.
• User & Group Management, to easily share virtual resources with other users and groups.
• Improved Security, that fixes security issues and incorporates new authentication drivers and performance improvements.
• Networking Drivers, a new set of drivers are now available to perform networking setup operations.
• Data Center Placement Policies, placement policies can be defined globally to optimize the resources of the datacenter. There are 4 predefined policies: packing, striping, load-aware, and custom.

We also recently updated the OpenNebula Public Cloud to OpenNebula 3.2.

Please note that, a few days ago, we released OpenNebula 3.2.1, a maintenance release that includes several bug fixes. This is a recommended update for everyone running the 3.x version of OpenNebula.

As we mentioned in our last newsletter, one of the new features in OpenNebula 3.x that is getting a lot of attention is OpenNebula Zones. We published a screencast that explains this feature in more detail, which we recently followed up with a second screencast showing how to manage Virtual Data Centers in OpenNebula.

Community

Ken Barber, from Puppet Labs, wrote a blog post (co-authored with our own Tino Vazquez) on how to “puppetize OpenNebula”, describing the integration between Puppet and OpenNebula.

The Business Application Modernization (BAM) Department of IBM India contributed two really interesting blog posts on using OpenNebula with Nested ESX VMWare, and on Using HybridFox and EC2 Interfaces on VMware-based OpenNebula Clouds.

We have a new contribution to the OpenNebula ecosystem: CLUES (Cluster Energy Saving), an energy management system for High Performance Computing (HPC) Clusters and Cloud infrastructures. The main function of the system is to power off internal cluster nodes when they are not being used, and conversely to power them on when they are needed. Thanks to the Grid y Computación de Altas Prestaciones (GRyCAP) group at the Universidad Politécnica de Valencia for this contribution!

oVirt and OpenNebula were featured as the main new components in cloud and virtualization in Fedora 17.

A new book titled “Open Source Cloud Computing Systems” (by Luis Vaquero, Juan Cáceres, and Juan Hierro) was just published, including a chapter on OpenNebula.

Sebastien Goasguen posted a video showing how to upload Virtual Machine Images to an OpenNebula cloud via S3 and Boto. The Austin on Rails group posted a video showing how to deploy Rails to your own private cloud with OpenNebula and Cobbler

SARA launched its new Cloud with OpenNebula 3. Some of their first users gave it glowing reviews.

Outreach

We have the following events coming up:

• OpenNebula will participate in the Open Source Virtualization and Cloud devroom at FOSDEM 2012 (Free and Open source Software Developers’ European Meeting), Brussels, Belgium, February 4-5, 2012.
• We will be giving an invited talk at Cloudscape IV – Advances on Interoperability & Cloud Computing Standards, Brussels, Belgium, February 23-24, 2012
• A workshop on basic and advanced use of OpenNebula will take place in the Open Source Datacenter Conference (OSDC) in Nuremberg, Germany, April 24-26, 2012

Remember that you can see slides and resources from past events in our Outreach page.

C12G Labs has just announced an update release of OpenNebulaPro, the enterprise edition of the OpenNebula Toolkit. OpenNebula 3.2, released two weeks ago, brings important benefits to cloud providers with a new easily-customizable self-service portal for cloud consumers, and builders with full support for VMware that now includes live migration, advanced contextualization and image management. The new release additionally included important enhancements in networking and security.

C12G delivers OpenNebulaPro for business, government, or other organizations looking for a hardened, certified, supported cloud platform. OpenNebulaPro combines the rapid innovation of open-source with the stability and long-term production support of commercial software. Compared to OpenNebula, the expert production and integration support of OpenNebulaPro and its higher stability increase IT productivity, speed time to deployment, and reduce business and technical risks.

OpenNebulaPro 3.2 integrates the most recent stable version of OpenNebula 3.2 with the bug, performance, and scalability patches developed by the community and by C12G for its customers and partners. Supported Linux distributions are RedHat Enterprise Linux, Suse Linux Enterprise, CentOS, Ubuntu, Debian and OpenSuse; supported hypervisors are VMware, KVM and Xen; and the supported cloud provider for cloudbursting is Amazon Web Services. OpenNebulaPro 3.2 is provided under open-source license to customers and partners on an annual subscription basis through the OpenNebula.pro Support Portal.

C12G offers a 30-day, no-cost, and no-commitment trial of OpenNebulaPro with the services to assess its suitability and performance in your environment.

The OpenNebula Project is pleased to announce the continuation of its collaboration with Microsoft on innovation and interoperability in cloud computing. The OpenNebula Project and Microsoft started to collaborate in Summer 2011 aimed at adding and mantaining Hyper-V on the list of officially supported hypervisors. A first collaboration was announced in September 2001. As a result,  in October 2011, we released under the Apache license a development version of the new plug-ins to build clouds on Microsoft Hyper-V.

The aim of this second collaboration is to bring the existing prototype to a more stable version and to enhance its features. Since the release of the first prototype, the OpenNebula project has provided support for the deployment and tuning of the new drivers to several users. These users have provided relevant feedback on functionality, stability and performance that will be addressed in the new version. You can find more technical details in the Hyper-V page of the OpenNebula ecosystem.

Great news!, and stay tuned, the new version will be ready in Q1 2012.

January 30th, 2012. After 2 weeks from OpenNebula 3.2 release, the OpenNebula project announces the general availability of OpenNebula 3.2.1. This is a maintenance release that collects all the great feedback received since 3.2 release.

This release only includes bug fixes (check here for a list of issues solved) and is a recommended update for everyone running any 3.x.

Check out the OpenNebula 3.2 release notes for the release highlights and a summary of the new features incorporated in OpenNebula 3.2.

Relevant Links

• Download OpenNebula 3.2.1
• Release notes
• Documentation

The OpenNebula Team

Last week I was invited by the Russian Space Research Institute (IKI) at Moscow to give a talk on cloud computing in the context of our collaboration within the Mars MetNet Mission.

An overview of the technology focusing on our efforts in European FP7 projects (4CaaSt among others) along with our latest achievements in the porting and optimization of critical applications were shown. Also, meetings were held in order to study the possibility of extending our collaboration to other space missions and not only to planet Mars.

Thanks to IKI I had the opportunity to visit the “Star City”, also known as “Yuri Gagarin Cosmonaut Training Center”, where all astronauts traveling to the International Space Station perform their preparation.

So far, the publications produced by this research line are the following:

• J.L. Vázquez-Poletti, G. Barderas, I.M. Llorente and P. Romero: A Model for Efficient Onboard Actualization of an Instrumental Cyclogram for the Mars MetNet Mission on a Public Cloud Infrastructure. PARA2010: State of the Art in Scientific and Parallel Computing, Reykjavík (Iceland), June 2010. Proceedings published in Lecture Notes in Computer Science (LNCS). Volume 7133, pp. 33-42, 2012. Springer Verlag.
• Pilar Romero, Gonzalo Barderas, Jose Luis Vazquez-Poletti and Ignacio M. Llorente: Temporal Areographic Patterns of Phobos Eclipses on Mars for the Metnet Precursor Mission. 8th European Geosciences Union (EGU) General Assembly 2011 (EGU 2011), Vienna (Austria), April 2011. Proceedings published in Geophysical Research Abstracts. Volume 13, EGU2011-6470, 2011. Copernicus Publications.
• P. Romero, G. Barderas, J.L. Vázquez-Poletti and I.M. Llorente: Chronogram to detect Phobos Eclipses on Mars with the MetNet Precursor Lander. Planetary and Space Science, vol. 59, n. 13, 2011, pp. 1542-1550.
• A.-M. Harri, W. Schmidt, P. Romero, L. Vazquez, G. Barderas, O. Kemppinen, C. Aguirre, J.L. Vazquez-Poletti, I.M. Llorente and H. Haukka: Phobos eclipse detection on Mars, theory and practice. Technical Report, 2012 (to be published), Finnish Meteorological Institute, Finland.

J.L. Vázquez-Poletti

It's finally here -- the final release of Nimbus Infrastructure 2.9!

The major additions in this release are support for Availability Zones, configurable EC2 multi-core instances, more robust support for LANTorrent and new administration tools which allow administrators to easily control VMs running on their cloud. The administrators can also choose to give more information to the user, e.g., allow them to inspect on what physical machines a their virtual machines are running.

In addition, the release also includes bugfixes and additions to documentation. Check out the changelog for full details.

As always, we want to express our gratitude to our open source community for their contributions to this release. We would like to particularly acknowledge the work of Rob Rusnak who contributed the administrative tools as part of the Google Summer of Code project and Shao, Hsin (Jeff) who helped with LANTorrent testing. The features in this release were supported by the GSoC, OOI, and FutureGrid projects.

The Nimbus Infrastructure 2.9 release is available for download at: http://www.nimbusproject.org/downloads/

Documentation is available at: http://www.nimbusproject.org/docs/2.9/

Previously, developers had to put a lot of energy into preserving choice across operating systems and minimizing hard dependencies on specific operating systems.  In the cloud era, there is a similar challenge to preserve choice across clouds and minimize dependencies on specific clouds.

Most PaaS solutions today force you to write your application to that specific PaaS and that is where your app will stay, much like writing to an OS.  It sits on a public cloud somewhere and cannot be moved without recoding and dependency swaps.  In extreme cases, you as a developer are still directly tied to the constraints of the infrastructure.

Limiting yourself to a single cloud instance restricts your flexibility now and in the future. You may want to move from private to public cloud, or vice versa.  You may want to change from one public cloud provider to another or maybe you are dissatisfied with the pricing or reliability from a particular provider.  Geographic market expansion or compliance needs may push you to new clouds.  Building and deploying applications to clouds that have a proprietary deployment and/or technology stack will impede your cloud flexibility.  You want to preserve your “Multi-Cloud” ability.

Cloud Foundry gives you the ability to make your application Multi-Cloud by allowing you to write your application once and deploy it to any Cloud Foundry instance, be it public or private or even on to Micro Clouds.

The Cloud Foundry eco-system has grown a great deal in the last 9 months.  There are now multiple public clouds based on Cloud Foundry and several private cloud deployment options that rely on Cloud Foundry.  In addition, we also offer Micro Cloud Foundry (Cloud Foundry in a VM).  All of these options have the ability to take the same Java, Ruby, or other code and deploy an application without modification.

How does Cloud Foundry achieve Multi-Cloud Application Portability?

There are several technologies at work to make Multi-Cloud a reality.

DEAs – The Dynamic Execution Agents operate as independent entities that carry out requests made by the Cloud Controller.  By being independent, DEAs provide a place for the Application to run without the application being aware of where it is executing (like in a traditional OS).
Service Gateways – Provide a common/uniform way of exposing Services (Databases, Message Queues, Stores, etc.) to the Applications running on the DEAs.  By presenting services in a common and uniform way to a running application, it becomes more easily portable.
Environmental Variables – The last portion to make applications portable is to provide credentials for services in a standard way to all application runtimes.  In all Cloud Foundry implementations, this is done by injecting a JSON document as an environment variable that lists all bound services and their credentials to the Application.  Once a developer has written their code to leverage this (either by parsing the JSON themselves or by leveraging a framework feature such as Spring 3.1 Profiles, the application can be run on any instance of Cloud Foundry without modification to any of the code.

Below is a 5 Minute video showing a Multi-Cloud Deployment to 5 different Cloud Foundry based Clouds

Multi-Cloud using Cloud Foundry – The Demo

(For the fully detailed 13 minute version, click here)

Steve Herrod, VMware’s Chief Technology Officer further discusses the advantages of the Multi Cloud approach to PaaS in the following blog post.

Watch a short flash video – “Multi-Cloud and Proud”

-The Cloud Foundry Team

Don’t have a Cloud Foundry account yet?  Sign up for free today

The OpenNebula Cloud offers a virtual computing environment accessible through two different remote cloud interfaces, OCCI and EC2, and  two different web interfaces,  Sunstone for cloud administrators and the new SelfService for cloud consumers. These mechanisms access the same infrastructure, i.e. resources created by any of the mentioned methods will be instantly available on the others. For instance, you can create a VM with the OCCI interface, monitor it with the EC2 interface, and shut it down using the OpenNebula Sunstone web interface.

This Cloud has been migrated to the last OpenNebula version, 3.2. If you have an account you can still use your old username and password. If not, request a new account and check out the new OpenNebula 3.2 features. These interfaces will show you the regular user view of the Cloud, but you will not be able to manage ACLs, hosts, groups nor users, since that will be delegated to the oneadmin group.

Cloud Foundry is a sponsor and participant in this week’s Node Summit in San Francisco, so it is a good time to recap some of our work with node.js.

We’re finalizing node.js 0.6.7 support, which will be committed to the Cloud Foundry GitHub repository.  Cloud Foundry.com will begin to support node.js 0.6.7 as a runtime framework in the next week or two.  Because of the rapid pace of innovation around node, we are adding node.js 0.6.7 as an additional runtime, letting you select which version of node you want to run with your application.  This lets Cloud Foundry support multiple node.js versions simultaneously, which is important as it allows applications written against the node.js 0.4.12 version to co-exist with applications developed on node.js 0.6.7.

This work represents the first fruits of our partnership with Joyent, who is the Cloud Foundry Community Lead for node.js.  Going forward, we will have a joint open source engineering model with Joyent that lets the Cloud Foundry, node.js, and Redis teams all work together to deliver a highly optimized PaaS solution across those components.

The next few months should be big for node.js and the community around it.  Modern applications are becoming more demanding, diverse, and complex.  We see node.js as a great fit in addressing many of the problems posed by this.  A few examples of the efforts going into leveraging node.js with Cloud Foundry are covered in the links below.

• Using MongoDB, Redis, node.js, and Spring MVC in a Single Cloud Foundry Application
• Getting Started with VMware Cloud Foundry, MongoDB, and node.js
• Using the RabbitMQ Service on Cloud Foundry with node.js

- The Cloud Foundry Team

Don’t have a Cloud Foundry account yet?  Sign up for free today

A new episode of the screencast series is now available at the OpenNebula YouTube Channel.

This screencast, second part of the oZones screencast, shows how to manage and use Virtual Data Centers, both with the oZones CLI and with the oZones web-based interface, to isolate virtual infrastructure environments within an OpenNebula zone. It shows how to create a VDC by assigning a group of users to a group of physical resources and by granting one of the users, the VDC administrator, with privileges to manage all virtual resources in the VDC. The users in the VDC, including the VDC administrator, only see the virtual resources and not the underlying physical infrastructure, and can create and manage virtual compute, storage and networking capacity.

Enjoy the screencast!

An new incremental stable release of the GridWay Metascheduler is available for download.

It adds missing files for installing some MADs, and fixes bugs in the CREAM and BDII drivers. If you have GridWay working, there is no need for upgrading.

You can find more information in the release notes.

Enjoy! And let us know.

The GridWay team.

Our latest work in the context of the Mars MetNet mission has been featured on Datanami, an on-line publication devoted to Big Data. This mission brings together Finland, Russia and Spain, aiming to deploy a meteorological network on the Mars surface consisting in several tens of probes.

This time, the challenge has to do with the data gathered  by NASA’s Viking landers 40 years ago. Its re-process will not only aid in the formulation of valid Martian weather models but also to improve the Cloud framework that will be used for the future data from the Mars MetNet probes.

You can read the full article here.

J.L. Vázquez-Poletti

January 17th, 2012. The OpenNebula project is happy to announce the availability of the stable release of OpenNebula 3.2. This release of OpenNebula features important improvements in security, networking and user management. It also fully integrates C12G addons, previously only available for OpenNebulaPro customers.

As main new features, OpenNebula 3.2 incorporates an easily-customizable self-service portal for end-users that greatly simplifies VM provisioning in the data center. This new update of OpenNebula also brings the highest levels of flexibility, stability, scalability and functionality for VMware-based data centers and clouds in the open-source domain. OpenNebula 3.2 provides an open management platform that compares to vCenter and vCloud, that can moreover be adapted to fit into your environment.

As usual OpenNebula releases are named after a Nebula. The Red Spider Nebula (NGC 6537) is a bipolar planetary nebula in the constellation Sagittarius.

Highlights of OpenNebula 3.2

Notable improvements include, but are not limited to:

• VMware, out-of-the-box support for VMware that now includes live migration, advanced contextualization, image and network management.
• Self-Service Portal, a new easy-to-use web-based end-user interface that complements the existing GUIs for the operation of the data-center (OpenNebula Sunstone) and for the management of multiple zones (OpenNebula Zones).
• User & Group Management, to easily share virtual resources with other users and groups.
• Improved Security, that fixes security issues and incorporates new authentication drivers and performance improvements.
• Networking Drivers, a new set of drivers are now available to perform networking setup operations.
• Data Center Placement Policies, placement policies can be defined globally to optimize the resources of the datacenter. There are 4 predefined policies: packing, striping, load-aware, and custom.

Relevant Links

• Download OpenNebula 3.2
• Complete Release notes
• Documentation

The OpenNebula Team

Work done by Debasis Roy Choudhuri, Bharat Bagai, Joydipto Banerjee, Udaya Keshavadasu, Rajeev D Samuel, Mitesh Chunara & Krishna Singh at the Business Application Modernization (BAM) Department of IBM India.

In our previous post, we had shown how to implement Cloud management with OpenNebula in a nested VMware environment. That is mostly a Cloud administration work. In this blog, we will focus more from the end users’ point of view. This exercise was also done at the Business Application Modernization (BAM) department of IBM India.

Scope

The goal was to setup a self-service portal based on EC2 query interface from where Cloud users can provision and launch various images that are available. Also users can avail the Public Cloud services of Amazon.

Implementation

To test this scenario we can use either HybridFox or ElasticFox plug-ins. In our scenario, we used HybridFox version 1.7.000119 on client end with Mozilla browser. On FrontEnd machine, you have to install the pre-requisite called ‘gems’ to access amazon-ec2 like interface. Later on with the help of this interface you can connect to Amazon Web Services. There will be certain changes in configuration files that you have to perform on FrontEnd machine.

• File econe.conf:
  :one_xmlrpc: http://localhost:2633/RPC2
  :server:
  :port: 4567
  :auth: ec2
  :instance_types:
  :m1.small:
  :template: m1.small.erb
  
• File EC2QueryClient.rb: Verify that Signature Method refers to ‘HmacSHA256′
• File EC2CloudAuth.rb:
  # Calculates signature version 1
  def signature_v1(params, secret_key, digest='sha1')
  params.delete('Signature')
  + params.delete(:econe_host)
  + params.delete(:econe_port)
  req_desc = params.sort {|x,y| x[0].downcase <=> y[0].downcase}.to_s digest_generator = OpenSSL::Digest::Digest.new(digest)
  

Once you integrate plug-in with Mozilla and restart econe service on FrontEnd machine, go to Mozilla browser and add your region

Here, AWS Secret Access Key refers to SHA1 password that you can see through oneuser command

Then you will get your EC2 Interface.

This way, you can add more regions with credentials to access other’s cloud. You can also launch virtual machines and other stuff from this interface.

Bharat Bagai
bbagai@gmail.com, bagai_bharat@hotmail.com

The International Workshop on Clouds for Business and Business for Clouds (C4BB4C) will be held at the 10th IEEE International Symposium on Parallel and Distributed Processing with Applications (ISPA2012).

Cloud Computing has acquired enough maturity to expand its field of application to business. Yet there are not only institutions which use this paradigm in their production line but there are also those which are offering services through the cloud.

This workshop intends to put together efforts done from service producers and consumers in order to make Cloud Computing provide an added value to the economy of any kind of institution. Technologies, policies and heuristics will be shared, not discarding those coming from other areas that would benefit Cloud Computing.

The Workshop intends also to focus on how services are delivered through the cloud as a popular strategic technology choice for businesses that provides a flexible, ubiquitous and consistent platform accessible from anywhere at any time.

The interface of software services and cloud computing provides a rich area for research and experience to give a unique insight into how cloud-based service can be achieved in practice. We encourage submissions of research papers on work in the area of Cloud Computing, Service Engineering, and especially welcome papers describing developments in cloud-enabled business process management and all related areas, such as deployment techniques, business models for cloud-based enterprises and experience reports from practitioners.

Extended version of selected papers will be included in a special issue of Scientific Computing: Practice and Experience.

This Workshop couldn’t be possible without the following projects: MEDIANET (Comunidad de Madrid S2009/TIC-1468), HPCcloud (MICINN TIN2009-07146) and 4CaaSt (Gr. Agree. 258862).

J.L. Vázquez-Poletti

The popular Java reporting engine from JasperSoft is now available as a Cloud Foundry package. With two simple commands developers can make JasperReports Server available on Cloud Foundry and build powerful reports querying  Cloud Foundry data services.  Deploying  JasperReport server using the Cloud Foundry command line tool (‘VMC’) is as simple as ‘vmc push’ and  ‘vmc bind-service’.

Cloud Foundry is a strategic platform for many users . As more applications get deployed to Cloud Foundry open PaaS, more developers will find the need to perform reporting and analysis (Business Intelligence) on the data that they are gathering. You could write your own reporting features… but that’s a lot of work, and it’s generally not your core strength. It makes sense to focus on improving your own application, and then embed analysis and reporting features.

With that in mind, we wanted to make JasperReports Server available on Cloud Foundry. It’s a logical extension for the most widely used Business Intelligence solution to move into the PaaS world.

The accompanying video shows how to configure and install JasperReports Server on Cloud Foundry.  We will review the steps in the details of the sections below.

By default, JasperReports Server (JRS) requires a JNDI connection to a database to hold its metadata repository. Normally it’s defined like this in applicationContext-webapp.xml:

<!-- define datasource for repository -->
<bean id="dataSource">
<property name="jndiName" value="java:comp/env/${metadata.hibernate.dataSource.jndiName}"/>
</bean>

While JNDI is not supported on Cloud Foundry, the standard Spring DataSource is available. So the change was relatively simple:

<!-- define datasource for repository -->
<cloud:properties id="cloudProperties"/>

<bean id="dataSource"
destroy-method="close">
<property name="driverClassName" value="${db.driverClassName}" />
<property name="url" value="${db.url}" />
<property name="username" value="${db.username}" />
<property name="password" value="${db.password}" />
</bean>

There are a few additional details around creating and referencing a new file called data-services.properties which contains the values for connecting to the repository database. We had to reference this file in applicationContext-webapp.xml:

<!-- pull in properties -->
<bean id="propertyConfigurer">
<property name="locations">
<list>
<value>/WEB-INF/hibernate.properties</value>
<value>/WEB-INF/data-services.properties</value><!-- Added for CloudFoundry support -->
</list>
</property>
<property name="properties" ref="cloudProperties"/><!-- Added for CloudFoundry support -->
<property name="localOverride" value="true"/><!-- Added for CloudFoundry support -->
</bean>

The file data-services.properties contains a mix of static default values and values that are populated dynamically by Cloud Foundry. For example, a developer is free to modify the name of the JasperReports Server repository database, but by default we assume it will be called “jrs-repo”. On the other hand, the connection information is dynamically generated when the application is deployed. Here are a few lines from the file:

serviceName=jrs-repo
db.name=${cloud.services.${serviceName}.connection.name}
db.url=jdbc:${serviceType}://${db.host}:${db.port}/${db.name}
db.username=${cloud.services.${serviceName}.connection.username}

After making this modification to get connected to the database, we needed to populate it. When using JasperReports Server in a standard on-premises situation, we would run a script that creates and populates the database. When deploying to Cloud Foundry we don’t have quite the same options. “Caldecott”, a new feature that allows developers to open a tunnel to any Cloud Foundry data service via a local port, is beginning to change this. But to fit into the PaaS world seamlessly, it makes more sense to have our application “bootstrap” the repository. Rather than assuming that the repository is already appropriately populated, we instead test on startup. If the required repository tables don’t exist, then we create them. This was the most significant change we made to our application, but it’s a feature that would make life easier for customers deploying on-premises as well. We plan to migrate this feature into our core product.

With these two changes in place, we were able to push the application up to Cloud Foundry and have it automatically configure itself and start working. But there was still one important piece to add.

The most common data source that a user needs for BI is a SQL data source. A connection to the database is normally created either by adding a JNDI data source or by defining a JDBC data source directly in the JasperReports Server user interface. But JNDI is not available, and you cannot define a JDBC data source if you don’t know your username and password. (It’s possible to determine your username and password for a database on Cloud Foundry… but part of the benefit is that you shouldn’t need to worry about it.)

We needed a custom SQL data source that is Cloud Foundry-aware. This required a new class that extends the JasperReports class BaseJdbcDataSource which adds support for Cloud Foundry’s RdbmsServiceInfo to get database connection information.

Likewise, Jaspersoft already has a connector for MongoDB, but this needed to be extended to include Cloud Foundry’s MongoServiceInfo class and provide for a Cloud Foundry-aware MongoDB data source. With these two additional .jar files and corresponding applicationContext files, we were then ready to deploy JasperReports Server to Cloud Foundry.

The following excerpt is from deploying JasperReports server to the Cloud Foundry and then binding an existing database to it so that we can begin creating reports and performing analysis. Typically an application will use either MySQL or PostgreSQL or MongoDB, but for our tests we used all three at once.

>vmc push
Would you like to deploy from the current directory? [Yn]: Y
...
Would you like to bind any services to 'jrs-community-421'? [yN]: y
The following system services are available:
1. mongodb
2. mysql
3. postgresql
4. rabbitmq
5. redis
Please select one you wish to provision: 2
Specify the name of the service [mysql-a8ec3]: jrs-repo
Creating Service: OK
...
Push Status: OK

vmc bind-service postgresql-data jaspersoft-421
vmc bind-service mongodb-data jaspersoft-421

By taking advantage of the ‘bind-service’ command end users avoid any additional configuration when attaching data sources for reporting e.g.: manually entering the IP address of the datastore, entering the name of the database, managing credentials, selecting a port number, constructing the target URL, or defining the JNDI source.

Cloud Foundry’s simple ’bind-service’ semantics transforms the eight step process above into one simple command.

Additional Information:

• Download JasperReports Server
• Check out the project wiki
• Watch the tutorial video

We are excited about the power of the Cloud Foundry ecosystem and the ease with which one can now use BI in the cloud. We are eager to hear feedback from the Cloud Foundry community as folks start using Jaspersoft to analyze and report on data.

A Guest Blog Post by Matthew Dahlman, Jaspersoft

Don’t have a Cloud Foundry account yet? Sign up for free today

Work done by Debasis Roy Choudhuri, Bharat Bagai, Joydipto Banerjee, Udaya Keshavadasu, Rajeev D Samuel, Mitesh Chunara & Krishna Singh at the Business Application Modernization (BAM) Department of IBM India.

In this blog we try to highlight some of the key elements involved in building a private Cloud environment using OpenNebula.

Scope

The goal was to setup a Platform-as-a-Service (PaaS) sandbox environment, where our practitioners can get a hands-on practice on various open Source based tools and technologies. We were successful in creating an On-Demand model where Linux based images having required software (e.g. MySQL, Java or any configurable middleware) could be provisioned using the OpenNebula web based interface (Sunstone) along with email notification to the users.

The highlight of the entire exercise was using nested Hypervisors to setup OpenNebula cloud – a feature which was probably being tried out for the first time (we checked the public domain and OpenNebula forums where nobody was sure if such a scenario existed; and were not certain if it was feasible ).

Implementation

We started with OpenNebula version 2.2 and then later on upgraded to 3.0. Hypervisor used was VMware ESX 4.1 and Centos 5.5 & 6.0 OS was used for the provisioned images. The hardware employed was IBM System x 3650 M2 for Cloud Management environment and administration while IBM SAN storage for provision of images.

Here’s the architecture diagram -

We have configured the above scenario in a single ESXi box (Physical Server).

As you can see in the architecture diagram, we configured OpenNebula(Front end) to use the VMware hypervisor(ESXi VM) to host VMs, the VSphere client on a Windows VM to access the ESXi(for admin work). One VM was designated as Image repository where all client images were stored. We also configured NFS on Image repository VM.

Note: – Before starting the installation, you have to install EPEL (Extra Packages for Enterprise Linux). EPEL contains high quality add-on packages for Centos and other Scientific Linux that will be required for compatibility with OpenNebula.

For storage space, we used NFS for OpenNebula and VMware storage. For that we created a separate NFS server or you can use same server. The following is the architect diagram that we used –

In above diagram, we are using SAN storage and mapped it to physical ESXi. After that, storage space has been distributed among VM’s. For Image repository, we took a large chunk of space to make it as NFS server also. This large chunk of space has been shared between ESXi and Front End. Naming of NFS storage space should be same here for all three servers.

One more important point that I have to mention here is that the name of the datastore should be same in both VMware hypervisor and FrontEnd machine as shown below:

A point to note about the VMWare

Remember that your VMware ESX server should not be free version. Either it has to be a limited edition of 60 days or a complete licensed version. Otherwise you will get errors while deploying VM from FrontEnd machine. You may use the following to test VM functionality through command prompt.

/srv/cloud/one/bin/tty_expect -u oneadmin -p password virsh -c ESX:///?no_verify=1

Once the connectivity is established, you can create VM network and deploy VM from FrontEnd machine. I will recommend while creating vmdk file ( which you will later use as an image ), you should install VM tools also.

A point about using context feature:

At present context feature for VMware is not supported by OpenNebula 3.0. This feature has been made available for only KVM and XEN Hypervisors. With the help of context feature, OpenNebula FrontEnd can provide IP address, hostname, DNS Server, gateway, etc to client VM’s. As a workaround for VMware ESXi, we used an alternate method – writing a custom script that emulates OpenNebula’s Context features. This script provides IP address for client, hostname, VMID etc. After assigning these details to the VM, it emails the Cloud admin with the necessary information.

Hints and Tips

Some errors which surfaced during the OpenNebula installation and configuration and their solutions are given below:

1. During libvirt addon installation for VMware hypervisor, you might get the following error -Configure: error: libcurl >= 7.18.0 is required for the ESX driverSolution: Upgrade curl with latest version or curl 7.21.7# rpm –qa | grep –i curlTo remove curl, use following commands# rpm -e --nodeps –-allmatches curl
   # rpm -e --nodeps –-allmatches curl-devel

   And then configure curl with /usr

   To check curl version, you use use these commands,

   /usr/bin/curl-config –version
   curl -–version

   Now try to install libvirt with ESX , with the following command

   # configure --with-ESX

   Also check that your PKG_CONFIG_PATH refers to “/usr/lib/pkgconfig”.
   To check libvirtd version, you can use these commands

   #/usr/local/bin/virsh -c test:///default list

   or

   # /usr/local/sbin/libvirtd --version

   Also remember that your libvirtd package supports necessary ESX version.

2. You may also get errors during restart services –Starting libvirtd daemon: libvirtd: /usr/local/lib/libvirt.so.0: version `LIBVIRT_PRIVATE_0.8.2' not found (required by libvirtd)Solution: Uninstall libvirtd and then configure libvirtd again with libraries path. Command – #./configure --with-ESX PKG_CONFIG_PATH="/usr/lib/pkgconfig" --prefix=/usr --libdir=/usr/lib64

Challenges Faced

The team faced several challenges during the journey. Some of the interesting ones are highlighted as follows:

• Minimize the infrastructure cost on Cloud physical servers. Workaround: Usage of VMs for cloud components like OpenNebula Front End, Image Repository and Host; usage of VLAN with private IP addresses
• Minimize the cost of provisioning public IP addresses in IBM corporate network for the Cloud infrastructure and the VMs. Workaround: Deployment of dynamic host configuration in the cloud environment with a range of private IP addresses
• Minimize VMware Hypervisor licensing costs. Workaround: Resolved this issue by building a VM with VMware vSphere ESXi hypervisor on parent ESXi hypervisor (nested Hypervisor scenario).
• Configuring a GUI for OpenNebula administration tasks. Workaround: Installing the Sunstone as an add-on product for provisioning of image, creation of VM’s etc & making it compatible with VMware Hypervisor
• Accessibility of the private VMs in the cloud within IBM network. Workaround: Leveraged SSH features: tunneling and port forwarding
• Limitations of OpenNebula product in passing the host configuration to VMs. Workaround: Internal routing for the cloud components and the VMs in the cloud and deployment of dynamic host configuration in the cloud environment
• Dynamic communication to the cloud users/admin on provision/decommission of VMs and host configuration/reconfiguration of the VMs in the cloud. Workaround: Use hooks feature of OpenNebula and shell scripts to embed customized scripts in VM image

Bharat Bagai
bbagai@gmail.com, bagai_bharat@hotmail.com

Posted by Alex Suraci

Today, we added a new feature to Cloud Foundry command line tool (‘VMC’) that makes it easier to automate application deployments. The new feature, called “manifests”,  describe applications in human-editable manifest documents. Manifest documents can describe anything from a simple “Hello World” app to complex multi-app hierarchies with inter-application dependencies and service binding information.  The manifests feature not only adds ease-of-use to VMC, it also ensures consistency and reproducibility of application deployments in Cloud Foundry.

Overview

The manifests feature uses a YAML document, aptly named manifest.yml. You will typically place this manifest document in your app’s root directory, though you can specify a different location by telling VMC which to use with the -m flag. The manifest can be created by hand, automatically created after a vmc push, or explicitly with vmc manifest. With this manifest document, VMC will simply read the input values from the file rather than prompt you for each configuration.  Not only can you automate vmc push with manifests, you can also bypass interactive inputs for a large portion of VMC’s commands to make using the command-line tool more efficient and user-friendly. For example, you can leave the app name out when issuing a vmc update command, and VMC will retrieve the app name from an existing manifest document.

Here’s the full list of commands that can take advantage of the manifest document:

• vmc push: Now allows you to specify multiple services. Pushes with information from the manifest. If no manifest is found, it will ask if you want to create one after the interaction is finished.
• vmc stats, vmc update, vmc start, vmc stop: If no application name is given, it operates on the application(s) described by the manifest.
• vmc update: Syncs changes from the root of the application if a manifest is present.
• vmc start: Starts the applications in a multi-app deployment in the proper order (taking dependencies into account).
• vmc stop: Stops multi-app deployments by shutting down each app in the reverse of the order in which they were started.
• vmc restart: See vmc stop and vmc start.
• vmc delete: Delete the application

Note: For multi-app hierarchies, these will operate only on the sub-app you’re in, rather than always operating on every app in the hierarchy. To operate on every app, invoke the command from the root of the hierarchy.

Getting Started

First, install or update your Cloud Foundry command line tool (‘VMC’) to the latest preview version using the following command:

gem install vmc --pre

You can verify that you got the right version using:

vmc -v

which should show the version to be 0.3.16.beta.1 or higher.

The easiest way to get going is to get a manifest document generated from basic application info. If you haven’t pushed your app yet, you can start with vmc push as usual, which will now ask if you want to save the configurations as a manifest document:

hello-sinatra(master*) % vmc push
Would you like to deploy from the current directory? [Yn]:
Application Name: hello-sinatra
Application Deployed URL [${name}.${target-base}]: ${name}-suraci.${target-base}
Detected a Sinatra Application, is this correct? [Yn]:
Memory reservation (128M, 256M, 512M, 1G, 2G) [128M]:
How many instances? [1]:
Would you like to bind any services to 'hello-sinatra'? [yN]: y
The following system services are available
1: mongodb
2: mysql
3: postgresql
4: rabbitmq
5: redis
Please select the one you wish to provision: 2
Specify the name of the service [mysql-2cccd]:
Would you like to bind another service? [yN]:
Would you like to save this configuration? [yN]: y
Manifest written to manifest.yml.
Creating Application: OK
Creating Service [mysql-2cccd]: OK
Binding Service [mysql-2cccd]: OK
Uploading Application:
  Checking for available resources: OK
  Packing application: OK
  Uploading (1K): OK
Push Status: OK
Staging Application 'hello-sinatra': OK
Starting Application 'hello-sinatra': OK

As you can see, just before pushing, we were able to save the deployment configurations as manifest.yml in the same directory. Let’s take a peek into this file:

hello-sinatra(master*) % cat manifest.yml
---
applications:
  .:
    name: hello-sinatra
    instances: 1
    framework:
      name: sinatra
      info:
        exec: ruby main.rb
        description: Sinatra Application
        mem: 128M
    url: ${name}-suraci.${target-base}
    services:
      mysql-2cccd:
        type: :mysql
    mem: 128M

The manifest document has captured all of the configuration that we entered above for the application push into a description of the application deployment. Once you have a manifest.yml file, you can modify it however you would like, as it’s meant to be human-editable. The structure of the document is freeform, so if you want to define arbitrary values and use them throughout your document, you can.

Now if we try pushing again, vmc push will use this to automate everything:

hello-sinatra(master*) % vmc delete hello-sinatra
Provisioned service [mysql-2cccd] detected, would you like to delete it? [yN]: y
Deleting application [hello-sinatra]: OK
Deleting service [mysql-2cccd]: OK

hello-sinatra(master*) % vmc push
Would you like to deploy from the current directory? [Yn]:
Pushing application 'hello-sinatra'...
Creating Application: OK
Creating Service [mysql-2cccd]: OK
Binding Service [mysql-2cccd]: OK
Uploading Application:
  Checking for available resources: OK
  Packing application: OK
  Uploading (1K): OK
Push Status: OK
Staging Application 'hello-sinatra': OK
Starting Application 'hello-sinatra': OK

You can also use vmc manifest to create a manifest without pushing. vmc manifest will let you create more complex manifests describing multiple applications in a single hierarchy.

Now that you have a manifest document, you don’t really have to do anything else if you don’t want to get fancy. It’ll passively improve VMC’s user interface experience for the commands listed above: vmc push will be interaction-free, making deployment much easier, and many other commands will be efficient to invoke.

Getting Fancy Child Manifests

A manifest document can inherit properties from a parent manifest like so:

inherit: path/to/parent.yml

This slurps in everything from the parent document ensuring that properties defined in the child manifest are deep-merged with the parent. The symbols are resolved after this merge has taken place, so any properties you set in the child manifest may be used in properties set in the parent.

This allows you to provide the basic information, such as service bindings and framework information, in a “base” manifest, which can be “filled in” via a child manifest. For example:

• Having various child manifests for different deployment modes (e.g. debug, local, public) that extend base application information provided by a “base” manifest.
• Packaging the basic configuration along with your app, which users can extend with their own manifest to override your settings or fill in the blanks for their own deployment.

Symbol Resolution

There are currently two special symbols:

• target-base: The base URL of your target. For example, targeting api.cloudfoundry.com means a target-base value of cloudfoundry.com.
• random-word: A random string of characters. This is useful for ensuring your URLs are unique.

Otherwise, symbol resolution simulates lexical scoping, so you can define arbitrary properties, which can be overridden by child manifests or in a nested hash.

For example, the following parent:

applications:
  ./foo:
    name: bar
    url: ${name}.${target-base}

…combined with this child manifest:

applications:
  ./foo:
    name: baz

…and with a target of api.cloudfoundry.com, will result in a url of baz.cloudfoundry.com when using the child manifest, and bar.cloudfoundry.com when using the parent.

Multi-App Manifests

Manifests also present a way to deploy multiple applications through a single push command.  Let’s say you have a modular application comprised of several independent parts, for example, a publisher and a subscriber. You’ll want the subscriber to be started before the publisher, so it doesn’t miss anything that was published. It’s best to have these two applications defined as parts of a whole, where you can specify this dependency. This is done with multi-app manifest documents.

Our publisher app will publish messages every second, with the message starting at 0 and increasing for every iteration. The subscriber will simply collect the messages it receives in the order they came in, and display them to the user.

To start with, you may want to arrange your applications like so:

./big-app
./big-app/publisher
./big-app/subscriber

This will make using the manifest document more natural.

Switch to the big-app directory and use vmc manifest to create your manifest document:

~ % cd ./big-app
big-app % vmc manifest
Configure for which application? [.]: ./publisher
Application Name: publisher
Application Deployed URL [${name}.${target-base}]: publisher-${random-word}.${target-base}
Detected a Sinatra Application, is this correct? [Yn]:
Memory reservation (128M, 256M, 512M, 1G, 2G) [128M]:
How many instances? [1]:
Would you like to bind any services to 'publisher'? [yN]: y
The following system services are available
1: mongodb
2: mysql
3: postgresql
4: rabbitmq
5: redis
Please select the one you wish to provision: 5
Specify the name of the service [redis-47da2]: redis
Would you like to bind another service? [yN]:
Configure for another application? [yN]: y
Application path?: ./subscriber
Application Name: subscriber
Application Deployed URL [${name}.${target-base}]: subscriber-${random-word}.${target-base}
Detected a Sinatra Application, is this correct? [Yn]:
Memory reservation (128M, 256M, 512M, 1G, 2G) [128M]:
How many instances? [1]:
Would you like to bind any services to 'subscriber'? [yN]: y
The following system services are available
1: mongodb
2: mysql
3: postgresql
4: rabbitmq
5: redis
Please select the one you wish to provision: 5
Specify the name of the service [redis-a1278]: redis
Would you like to bind another service? [yN]:
Manifest written to manifest.yml.

In this single interactive session we’ve configured a manifest that defines two Sinatra apps, using a single Redis service. We’re using URLs with a bit of randomness (provided by the special random-word symbol) to ensure uniqueness.

There’s one thing missing, though. We didn’t specify any dependencies between the apps. If we were to start it now, we could lose some data if the publisher starts before the subscriber:

big-app % vmc push
Would you like to deploy from the current directory? [Yn]:
Pushing application 'publisher'...
# ...
Starting Application 'publisher': OK
Pushing application 'subscriber'...
# ...
Starting Application 'subscriber': OK

big-app % curl subscriber-bf872.cloudfoundry.com
Received: ["5", "6", "7", "8", "9"]

As you can see, we’ve lost some data here.  In the time between the publisher starting and then the subscriber starting, the subscriber has missed four messages.

This can be fixed by editing the manifest.yml document to indicate that the publisher depends on the subscriber being started:

---
applications:
./publisher:
# ...
depends-on: ./subscriber
./subscriber:
# ...

Now let’s delete both apps and retry.

big-app % vmc delete publisher
Deleting application [publisher]: OK

big-app % vmc delete subscriber
Deleting application [subscriber]: OK

big-app % vmc push
Would you like to deploy from the current directory? [Yn]:
Pushing application 'subscriber'...
# ...
Starting Application 'subscriber': OK
Pushing application 'publisher'...
# ...
Starting Application 'publisher': OK

As you can see, now the subscriber starts before the publisher. So we shouldn’t have any data loss this time.

big-app % curl subscriber-bf872.cloudfoundry.com
Received: ["1", "2", "3", "4", "5", "6", "7"]

Hooray!

Wrapping Up

The manifests feature is intentionally open-ended and flexible, providing the structure for you to define your deployments however you like. Kick the tires a bit and let us know how you think we should enhance this feature. Feel free to direct any suggestions or feedback to the support forums!

Alex Suraci, Cloud Foundry Engineering

Don’t have a Cloud Foundry account yet? Signup for free today

Happy New Year: Nimbus Infrastructure 2.9 RC2 is ready to come out!

The major additions in this release are support for availability zones, configurable EC2 multi-core instances, and new administrative tools which allows administrators to easily control VMs running on their cloud. The administrators can also choose to give more information to the user, e.g., allow them to inspect on what physical machines a their virtual machines are running.

In addition, the release also includes bugfixes and additions to documentation. Check out the changelog for full details.

Much of the effort for this release came from our open source community. We would like to particularly acknowledge the contributions of Rob Rusnak who contributed the administrative tools as part of the Google Summer of Code project. The features in this release were supported by the GSoC, OOI, and FutureGrid projects.

The Nimbus 2.9 RC2 is available for download at: http://www.nimbusproject.org/downloads/

Documentation (still in progress) is available at: http://www.nimbusproject.org/docs/2.9/

We appreciate help from all who are willing to test this release. To help provide an easy vehicle for feedback and resolve issues quickly we offer real-time access to a Nimbus RC chatroom for serious alpha testers. If you would like to participate, please contact us for access.