Release Notes Version 1.1.0

Introduction

The 1.1.0 release of jclouds includes results of 2 months effort by our contributors. A total of 30 Issues were addressed in this release. Highlights include more robust ssh connections via sshj driver, a more robust EC2 implementation, and support for the Green House Data vCloud. Many thanks to our contributors, Shikhar from sshj, and the cloud providers for facilitating the release.

As always, we keep our examples site up to date so you can see how to work this stuff. Next release will be in about a month and look for progress including CloudStack 2.2.8 and Softlayer providers in the next version.

Please submit your own ideas and let us know if there are features you’d like to see, need help on, or are interested in contributing. Make sure you follow us on Twitter for updates.

New Features

Green House Data vCloud Support

Green House Data run a completely wind-powered public vCloud offering in Wyoming, accessible as greenhousedata-element-vcloud in jclouds. Check out their site for more details.

SSHJ driver

Troubleshooting ssh connections consumed a lot of time during past releases of jclouds. This is because clouds have different operating system configurations, and sometimes distant or complicated networks between you and the nodes. Having a reliable ssh client implementation can significantly cut debugging time when problems occur. We’ve found [https://github.com/shikhar/sshj sshj] the most reliable and hackable open source java ssh library, and importantly with best feedback when failures occur. Here’s how to configure it, noting you’ll need to include the org.jclouds.driver/jclouds-sshj dependency in your codebase.

java

compute = new ComputeServiceContextFactory().createContext(provider, identity, credential, ImmutableSet.<Module> of(new SshjSshClientModule()), properties);

clojure

(def compute
  (compute-service provider provider-identity provider-credential :sshj))

Hostname in NodeMetadata

Those writing shell scripts from data inside !NodeMetadata often need to know what the local hostname is of the operating system you are working against. We now return hostname data on clouds that assign this value predictably, or null if unpredictable.

Configurable defaults for Multi-Site vCloud and Terremark installations

When working with a multi-site Terremark or vCloud provider, you may want to change the default datacenter or network to launch VMs into, rather than have jclouds pick one. With new configuration properties, you can specify the name of the Org, VDC, Catalog, and Network you prefer for a particular invocation of jclouds.

   overrides = new Properties();
   overrides.setProperty(VCloudConstants.PROPERTY_VCLOUD_DEFAULT_VDC, "MyCompany - MIA");
   context = new ComputeServiceContextFactory().createContext("trmk-ecloud", email, pass,
            ImmutableSet.<Module> of(new SshjSshClientModule()), overrides)

Amazon EC2 Image Filters

Even refining lists to a set of user ids, using EC2 can be bogged down, parsing the thousands of public images published by the Amazon EC2 community. Several users have expressed the desire to refine further, based on qualifications they choose. You can set a property to restrict the list to a subset matching any recognized image query.

   overrides = new Properties();
   // choose only amazon images that are ebs-backed
   overrides.setProperty(AWSEC2Constants.PROPERTY_EC2_AMI_QUERY,
                         "owner-id=137112412989;state=available;image-type=machine;root-device-type=ebs");
   context = new ComputeServiceContextFactory().createContext("aws-ec2", access, secret,
            ImmutableSet.<Module> of(new SshjSshClientModule()), overrides)

See EC2 Image Filters for more.

New syntax for creating EC2 ingress rules

For those using the “aws-ec2” provider, you’ll notice that AWS now supports security groups constraints that are more fine grained than before. For example, you can now assign rules constrained by source group and also port. We now have an fluent api for creating and applying ingress rules.

// get a hold of an ec2 client so you can access security group services
securityGroupClient = AWSEC2Client.class.cast(context.getProviderSpecificContext().getApi()).getSecurityGroupServices();

// create a new group and get back its id
groupId = securityGroupClient.createSecurityGroupInRegionAndReturnId(regionOrNull, groupName, groupDescription);

// add new rule(s) to the group
securityGroupClient.authorizeSecurityGroupIngressInRegion(regionOrNull, groupId,
               IpPermissions.permit(IpProtocol.UDP).fromPort(11).to(53)
                                                   .originatingFromSecurityGroupId("otherGroup"));

See Issue 606 for more examples.

Preferring S3-Backed Images in EC2

During the recent aws outage, instances which used EBS (elastic block store) were more impacted from an availability standpoint. We now have a template builder option that allows you to prefer instance store.

      // match the smallest hardware configuration that will run amazon linux with an S3-backed image.
      // Note that t1.micro does not support instance store, therefore this will match m1.small.
      Template template = templateBuilder.osFamily(OsFamily.AMZN_LINUX)
            .imageMatches(EC2ImagePredicates.rootDeviceType(RootDeviceType.INSTANCE_STORE)).build();

API Breakers

New Terremark and vCloud models

Terremark vCloud Express was the first operable vCloud Express environment. Over time, the vCloud model changed as did Terremark offerings, in different directions. Troubleshooting and coding these models became complicated over time, with vain attempts to share code across incompatible models. In the jclouds 1.1.0, we’ve cut vcloud models from Terremark models, simplifying maintenance of both. This doesn’t impact use of ComputeService, but it does impact the provider-specific terremark apis, as they’ve been repackaged under org.jclouds.trmk. Also, the maven dependencies of org.jclouds.api/vcloud, org.jclouds.provider/trmk-ecloud, and org.jclouds.provider/trmk-vcloudexpress have been refactored.

Cool Stuff

JBoss AS7 in our integration tests

Many jclouds ComputeService users install middleware via our runScript functionality directly as opposed to using a configuration tool. In order to test our ability to deploy simple configurations, we formerly used JBoss version 6.0. However, this took a long while to startup, was a big image, and generally slowed testing. Seeing tweets about version 7, we were quite excited to see improvements in test execution, based on claims. We’ve verified very fast startup, many times under 2 seconds using AS7 in our service-based testing. If you’d like more details or results, have a look at the [issue]http://code.google.com/p/jclouds/issues/detail?id=616) we migrated to AS7 in. Also, if you are interested in contributing a test using a different product, let us know!

Tracking

Status of the release is tracked in issue 641

Test Results