Automating Openstack Testing on Ubuntu

During the Ubuntu precise development cycle the Canonical Platform Server Team have been working on automating testing of Openstack on Ubuntu.

The scope of this work was:

1. Per-commit testing of Openstack trunk to evaluate the current state of the upstream codebase in-conjunction with the current packaging in Ubuntu precise and the current Juju charms to deploy Openstack.
2. SRU testing for Openstack Diablo on Ubuntu 11.10.

Openstack do a lot of pre-commit testing through the use of gerrit with Jenkins; we wanted to supplement this with Ubuntu focused testing to provide another dimension to the testing already completed upstream.

So grab a coffee and make yourself comfortable; this is not a short read….

Lab Setup

The Ubuntu Openstack QA lab consists of 12 servers; the primary server in the solution is an Ubuntu 11.10 install providing the following functions:

1. Juju – used to deploy Openstack charms in the Lab
2. Cobbler to support server provisioning (using the Ubuntu Orchestra packages in Oneiric)
3. Jenkins CI – provides triggering based on upstream commits to github repositories and general job control and reporting.
4. Schroots for Oneiric and Precise for building packages locally
5. A reprepro managed local archive for Oneiric and Precise
6. Squid based archive caching to reduce installation times in the lab

This server also acts at the gateway into and out of the Lab (it’s setup as a NAT router).

The other 11 servers are registered in Cobbler; All servers are connected to a Sentry CDU (Cabinet Distribution Unit) which allows full power control from Cobbler – thanks goes to Andres Rodriguez for developing the required fence component for Cobbler to support this type of CDU.

Preseeded LVM Snapshot Installs

To initiate a new integration test run requires all machines to be powered down and re-provisioned from scratch.  It is essential that our deployment and test runs can cope the frequency of upstream commits, particularly as the frequency increases as Openstack approaches milestones and releases.   After getting the initial lab setup in place, we were able to tear down all machines, re-provision and deploy Openstack in ~30mins.

It was important that we are able to minimize the time taken to complete the testing cycle.   To do so, we’ve employed the use of LVM snapshotting and restoration of the root partition during the the netboot installation.   The process is as follows:

1. Test run begins
2. Juju deploys a service (i.e. nova-compute)
3. A machine is netbooted and a preseeded LVM-based Ubuntu installation takes place onto /dev/qalab/root
4. At the end of the installation, the root filesystem is moved to /dev/qalab/pristine-[release]-root and a snapshot created at /dev/qalab/root
5. The machine reboots, runs Juju and deploys nova-compute as pat of the rest of the Openstack deployment. This deployment is smoke tested.
6. The next test run begins.  All machines are terminated. Juju redeploys nova-compute, a machine is netbooted and Ubuntu installation kicks off.
7. The installation checks for the existence of a logical volume at /dev/qalab/pristine-[release]-root.  If it exists, it creates a new snapshot at /dev/qalab/root and reboots. If it does not, continues with installation and goto step 4.
8. System reboots, Juju installs and redeploys nova-compute to a fresh Ubuntu installation.

This process takes place on all nodes in parallel.  With it in place, we were able to cut down the time it took to tear-down and re-provision a node from ~30 minutes to 10 to 15 minutes depending on the service being deployed.

By taking this approach we are also minimize the chance of any nodes hitting an archive inconsistency during installation. This is a known issue when deploying the development release and halts installation on any node that hits it, failing the entire deployment.

All of this is embedded in debian-installer preseeds via Cobbler snippets.  The snippets and kick starts are available at lp:~openstack-ubuntu-testing/+junk/cobbler-lvm-snapshot.

In the future, we’ll be investigating the use of kexec as an alternative to reboot after snapshot restoration to reduce the time spent waiting on servers to boot.  This should minimize the test cycle even more. Credit to James Blair for the idea (see http://amo-probos.org/post/11).

Management of Jenkins

All of the projects in Jenkins are managed using Jinja2 XML templates in-conjunction with python-jenkins (python-jenkins); this makes it really easy to setup new jobs in the lab and reconfigure existing ones as required (as well as providing great backup!).

Templates and management scripts can be found in lp:~openstack-ubuntu-testing/+junk/jenkins-qa-lab

Testing Openstack Essex on Ubuntu Precise

This testing was the first to be setup in the lab.  Jenkins (using the git plugin) monitors the upstream github.com repositories for commits on the master branch.  When a change is detected the following process is triggered:

Build

Objective: Validate that upstream trunk still builds OK with current packaging for Ubuntu.

1. A new snapshot upstream tarball is generated based on the latests commit to the upstream component.
2. The latest archive packaging for the component is pulled in from lp:~ubuntu-server-dev/<COMPONENT>/essex
3. Any changes in the testing packaging for the component are merged from lp:~openstack-ubuntu-testing/<COMPONENT>/essex
4. New changelog entries are automatically created for the new upstream commits.
5. The source package is generated and built in a clean schroot using sbuild locally.

On the assumption that the package built OK locally:

1. The source package is uploaded to the Testing PPA (ppa:openstack-ubuntu-testing/testing)
2. The testing packaging branch is push back to lp:~openstack-ubuntu-testing/<COMPONENT>/essex.
3. The binary packages from the sbuild are installed into the local reprepro managed archive.

This process is managed by a single script (tarball.sh); Credit to Chuck Short for pulling together this part of the process based on work from Openstack upstream.

For changes to the nova project the deploy phase is then executed.

Deploy

Objective: Validate that packages install, can be configured and reach a know good state prior to execution of testing.

This phase of testing uses Juju with Cobbler to deploy Openstack into the QA lab infrastructure; It utilizes branches of the Openstack charms to support use of a local archive along with a deployer wrapper around Juju written by Adam Gandelman which executes the actual deployment using Juju and monitors for errors.

The deployer is configured to know where to get the right codebase for the Openstack charms, which services to deploy and which relations to setup between services. As you can see from the above diagram this is non-trivial but the charms and Juju do most of the hard work.

Once Openstack is deployed successfully the test phase is then executed.

Test

Objective: Validate that the Openstack deployment in the lab actually works!

At this point, we can run any integration tests we wish against the newly deployed cloud.  This testing is able to help us achieve multiple goals:

• Early detection of upstream bugs that break Openstack functionality on Ubuntu
• Verification that packaging branches in the development version of Ubuntu are compatible with upstream trunk.
• Using these packages, verification that our Juju charms are deploying a functional Openstack cloud and are up-to-date with any deployment-related configuration changes upstream.

At the moment this phase looks like this:

1. Configure the Openstack deployment (Adams deployer script provides some utility functions for locating specific services in the environment)
   • Creates network configuration in Nova for the private instance network as well as a pool of public floating IPs.
   • Upload an image into the Glance server for use during testing
   • Creates EC2 credentials in the Keystone server for use during testing.
2. Run the devstack exercise test scripts which ensure basic functionality of the deployment. Currently, this includes:
   • Basic euca-tools EC2 API for starting and stopping instances
   • EC2 AMI bundle uploads
   • Floating IP allocation, association and connectivity to instance
   • Volume creation and attachment to instance

Note: These are the same sets of tests that are currently run against proposed commits to gerrit upstream.

Longer term we aim to use the Openstack Tempest test suite in the lab; Adam is currently working on getting this up and running.

Reporting

The Jenkins instance in the QA lab is not publicly accessible; however all jobs run in the lab are published out (using the Jenkins build-publisher plugin) to http://jenkins.qa.ubuntu.com so that people can see the current state of the testing packaging in Ubuntu precise.

We are also working on setting up email notifications.

Success so far

Juju charms deploy Openstack components in a configuration that is compatible with upstream trunk prior to updates to packaging in Ubuntu.  Previously packages were updated in the archive first while Juju charm updates lagged behind as incompatibilities were uncovered after the fact.

We enabled automated testing 2 days prior to the 3rd Essex milestone release.  We were able to uncover and help fix a handful of bugs upstream before the release, including critical bugs like 921784.  In the past, these bugs were typical uncovered after the release (both upstream and in Ubuntu).

Since E3, there have been even more critical bugs uncovered by this testing and fixed upstream, some of which are only applicable to Ubuntu-specific configurations (not tested upstream) and would have been uncovered by users after code hit the Ubuntu archive (See 922232).

Further Plans for the Lab

Pre-commit  testing of changes to stable branches;  The Ubuntu Server team are  working upstream on maintaining the stable branches of released versions  of OpenStack – this work will validate patches proposed to stable  branches in review.openstack.org against the current version of the  packaging in released versions of Ubuntu.  Initially this will target  Diablo on Ubuntu 11.10 but will also support Essex on Ubuntu 12.04 once  released.  Ideally the testing process will provide feedback on  review.openstack.org to help the stable release team review proposed  patches.

References

Jenkins job configurations: lp:~openstack-ubuntu-testing/+junk/jenkins-qa-lab

Scripts supporting the lab: lp:~openstack-ubuntu-testing/+junk/jenkins-scripts

LVM snapshot preseeds and Cobbler snippets: lp:~openstack-ubuntu-testing/+junk/cobbler-lvm-snapshot

All other relevant scripts, charm branches, etc: https://code.launchpad.net/~openstack-ubuntu-testing/

Credits

Overall management of delivery and general whip cracking: Dave Walker

Lab installation and base configuration: Pete Graner, Tim Gardner, Brad Figg, James Page

Fence agent for network power control of servers: Andres Rodriguez

Source package creation and build process: Chuck Short and James Page

Deployment testing using Juju: Adam Gandelman

Testing of Openstack: Adam Gandelman

Jenkins packaging, configuration and management: James Page

Gerrit Plugin for pre-commit testing and generally great ideas: Monty Taylor and James Blair

Writing and reviewing this post: Adam Gandelman, Chuck Short and Dave Walker.

Jenkins 1.424.2 in Debian unstable!

Just a short post to say that Jenkins 1.424.2 has landed in Debian; 1.409.3 was accepted a few weeks ago and I just uploaded 1.424.2 to unstable.

I expect to upload another version in the next few weeks to enable the SSH command line interface to Jenkins (requires some more Jenkins tool-chain work to get everything building from source).

Huge thanks go to Tony Mancill and Damien Raude-Morvan who have sponsored my Jenkins packaging work in Debian!

I’ll sync this new version over to Ubuntu precise (and push into the new Jenkins Backports PPA for Ubuntu 11.10) once alpha 2 is out of the door…

Introducing python-jenkins

Over the last 12 months I have made use of a great Python library originally written by Ken Conley in automating the various testing activities that we undertake as part of Ubuntu Development using Jenkins.

Python Jenkins provides Python bindings to the Jenkins Remote API.

I’m pleased to announce that Python Jenkins 0.2 is available in Ubuntu Oneiric Ocelot and the project has now migrated to Launchpad for bug tracking, version control and release management.

The 0.2 release includes a number of bug fixes and new methods for managing Jenkins slave node configuration remotely – this is already being used in the juju charm for Jenkins to automatically create new slave node configuration when slave node units are added to a deployed juju environment (blog posting to follow….)

A quick overview…

It’s pretty easy to get started with python-jenkins on the latest Ubuntu development release – if you are running an earlier release of Ubuntu then you can use the PPA (Natty only ATM but more to follow):

sudo apt-get install python-jenkins

The library is also published to PyPI so you can use pip if you are not running Ubuntu.

Here’s a quick example script:

#!/usr/bin/python
import jenkins
# Connect to instance - username and password are optional
j = jenkins.Jenkins('http://hostname:8080', 'username', 'password')

# Create a new job
if not j.job_exists('empty'):
    j.create_job('empty', jenkins.EMPTY_CONFIG_XML)
j.disable_job('empty')

# Copy a job
if j.job_exists('empty_copy'):
    j.delete_job('empty_copy')
j.copy_job('empty', 'empty_copy')
j.enable_job('empty_copy')

# Reconfigure an existing job and build it
j.reconfig_job('empty_copy', jenkins.RECONFIG_XML)
j.build_job('empty_copy')

# Create a slave node
if j.node_exists('test-node'):
    j.delete_node('test-node')
j.create_node('test-node')

You can find the current documentation here.

Happy automating!

Package rebuild testing using Jenkins and sbuild

I’ve been working on rebuilding the Java packages in the Ubuntu archive that depend on ‘default-jdk’ against OpenJDK 7 to see where we are likely to have issues if and when we decide to upgrade the default version of Java in Ubuntu to OpenJDK 7

You can see the results here (limited time offer only); and here are the details of how I setup this rebuild.

Setup your rebuild server

So first things first; the current development release of Ubuntu (Oneiric Ocelot) includes the most recent LTS release of Jenkins so installing its pretty easy as long as you are using this release:

sudo apt-get install jenkins


You probably want to configure Jenkins with an administrator email address and point it at a mail relay so that Jenkins can tell you about failures.

Next you need to install a few development tools to make it all hang together nicely:

sudo apt-get install ubuntu-dev-tools sbuild apt-cacher-ng

This should get you to the point where you can setup the jenkins account to use sbuild:

sudo usermod -G sbuild jenkins
sudo stop jenkins
sudo start jenkins

Create sbuild environments

I decided that I wanted to compare current build results with openjdk-6 against the rebuild with openjdk-7 so I created two sbuild environments on my server – one for openjdk-6 and one for openjdk-7:

mk-sbuild --name=oneiric-java-6 oneiric
mk-sbuild --name=oneiric-java-7 oneiric


You might have noticed that I also installed apt-cacher-ng – as alot of the dependencies that get downloaded are the same having a local apt cache makes alot of sense to speed things up; its pretty easy to point the schroots we just created at the local instance of apt-cacher-ng:

sudo su -c "echo 'Acquire::http { Proxy \"http://localhost:3142\"; };' > /var/lib/schroot/chroots/oneiric-java-6-amd64/etc/apt/apt.conf.d/02proxy"
sudo su -c "echo 'Acquire::http { Proxy \"http://localhost:3142\"; };' > /var/lib/schroot/chroots/oneiric-java-7-amd64/etc/apt/apt.conf.d/02proxy"

You will also need to setup some self signed keys to make sbuild work:

sudo sbuild-update -k

So we now have two sbuild environments setup – but we need one to point at openjdk-7 instead of openjdk-6 – I stuck a modified copy of java-common (which determines the default-jdk) in a PPA:

sudo schroot -c oneiric-java-7-amd64-source
apt-get install python-software-properties
add-apt-repository ppa:james-page/default-jdk-7

Obviously this could just as easily be an upgrade to mysql, postgresql or any other package of your choosing.

Setting up Jenkins

I split this rebuild into ‘main’ and ‘universe’ components and used a mutli-configuration project with axis for ‘package’ (containing the list of packages I wanted to rebuild) and ‘version’ (java-6, java-7); I’ve included the config.xml for one of the projects here.  You can also see the configuration here.

The build is a very simple script:

#!/bin/bash
export HOME=/var/lib/jenkins
rm -Rf *
pull-lp-source ${package}
sbuild -d oneiric-${version} -A -n ${package}*.dsc

That should do the trick; you can then submit the project for build and it will gradually churn through the packages emailing you with any failures.

Jenkins for Ubuntu Oneiric: Call for Testing

Jenkins 1.409.1 has landed in Ubuntu Oneiric Ocelot so now is the time to try it out and help with testing this new distribution model for Jenkins!

Getting Started

If you are not using the development release of Ubuntu, Oneiric Ocelot, grab a copy of the latest alpha-3 milestone pre-release:

• ISO Images: http://cdimages.ubuntu.com/releases/oneiric/alpha-3/
• Cloud Images: http://cloud-images.ubuntu.com/releases/oneiric/alpha-3/

Note that alpha releases are NOT always stable – be careful!  Jenkins is quite happy running on either a Desktop or a Server so take your pick.

Once you have an install of Oneiric Ocelot…

apt-get install jenkins


…should get you going.  Jenkins should startup and be visible on http://localhost:8080 (or the name of your server if you are installing it elsewhere).

A few things to note…

The package for Ubuntu differs in a few ways from the upstream Jenkins .deb packages you might have been using to-date:

• Plugins are not bundled by default – normally Jenkins ships with the following plugins:
  • SSH Slaves Plugin
  • Maven Integration Plugin
  • Subversion Plugin

  Plugins should be compatible with this distribution packaged version of Jenkins – these can be installed through the ‘Manage Plugins’ option within Jenkins as normal.  I would recommend installing the Maven Integration Plugin at a minimum.

• Native OS integration features that are disabled:
  • Solaris: support for libzfs and libembeddedsu4j.
  • Windows: native control of remote windows slaves, native integration with Windows process management, windows service deployment of Jenkins

  It is still possible to use Windows slaves; however they will need to be launched using JNLP from the slave itself.

• Branding: if available on the client, the Web UI will use the Ubuntu font.
• Packages + wrapper scripts are provided for:
  • Monitoring of arbitrary jobs: jenkins-external-job-monitor + see man jenkins-monitor-job for more details.
  • Jenkins CLI: jenkins-cli + see man jenkins-cli for more details.

Using Jenkins

The Jenkins website has a great getting started guide – see https://wiki.jenkins-ci.org/display/JENKINS/Use+Jenkins.

Obviously you can skip the ‘Installing Jenkins’ section.

Reporting Bugs

If you find any problems please report bugs here https://bugs.launchpad.net/ubuntu/+source/jenkins

You can also find me (jamespage) in #ubuntu-server on Freenode IRC most weekdays.

Enjoy…

Avoiding missing-classpath lintian warnings with Maven based packages

Whilst I’ve been preparing the large dependency chain to support Jenkins for upload into Debian and Ubuntu I came across a new lintian warning:

libakuma-java: missing-classpath libjna-java


This is a new check that validates that the jar files associated with a debian -java package have a Class-Path entry set in the META-INF/MANIFEST.mf file.

This is used by wrapper scripts to dynamically set the classpath for Java applications at runtime based on the libraries that they use.

However, if you are packaging Maven based projects you don’t get this set for free (although that would be a great feature for maven-debian-helper).

Luckily the javahelper package has a CDBS class that can help out; simply add javahelper to the Build-Depends for your package then follow these steps:

1) debian/rules

Add the javahelper.mk class into the make file:

#!/usr/bin/make -f

include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/javahelper.mk
include /usr/share/cdbs/1/class/maven.mk

...
2) Add a .classpath file for the binary package

In my case this gets dropped into debian/libakuma-java.classpath

usr/share/java/akuma.jar /usr/share/java/jna.jar

Rebuild your package; the jar files should now have Class-Path entries and you should be lintian clean.

Enjoy.

Jenkins for Ubuntu Natty: Call for Testing

Many of you may have wondered what I have been doing since UDS-N; some of you may have know that I have been working on packaging Jenkins (nee Hudson) from source along with all of its build dependencies (all 80 of them).

After just over 3 months I’ve managed to get a 99% built from source Jenkins into the Hudson Ubuntu Testing PPA; this is core Jenkins only at this point in time; no plugins come bundled (although you can still install them using the Plugin Manager).

Note that the PPA only provides packages for the Natty Narwhal development release.

If you want to help out with testing, read on….

Getting started

So first things first; lets add the Jenkins testing PPA and install the jenkins package:

sudo add-apt-repository ppa:hudson-ubuntu/testing
sudo apt-get update
sudo apt-get install jenkins

Wait some time and Jenkins should be up and running.

Accessing Jenkins

Once the package has installed you should be able to access Jenkins on http://localhost:8080 (or whatever server you installed it on).

Jenkins comes completely empty; no jobs, minimal configuration, no security.  Follow the normal Jenkins ‘Use Jenkins‘ guide to get started.

Reporting problems

This is a testing package so it ain’t going to be perfect. Please join the hudson-ubuntu-users team and subscribe to the mailing list on launchpad to discuss general issues and report problems.

You can also find me (jamespage) in #ubuntu-server on Freenode if you like to use IRC.

Whats still todo?

Well as I said this is 99% built from source; a few packages are either binary packages (built from jars) or packages that bundle their dependencies in the upstream source bundle. I’m working with upstream(s) to get these issues sorted.

That said, everything that is installed on your server or desktop in the jenkins package IS built from source. Offending packages are either used for testing or generating documentation during library builds.

I’m also going to start working on packaging a few core plugins from source (see the associated blueprint for details); for the time being you can download and install from within Jenkins. I will also create a patch so that this feature can be disable if required.  Please feel free to apply to join the team if you want to package a plugin.

The Future

Well ultimately probably the main Ubuntu archive and Debian; but lets leave that until next release….

And if you were wondering, Hudson renamed itself to Jenkins in late January (hence the Hudson name keeps creeping into this post).

Automating Ubuntu Server ec2 Testing – Part 1

Having automated the Ubuntu Server ISO testing process during the Maverick release cycle with Mathias Gug, I was keen to apply a similar automated testing approach to the Ubuntu Server AMI’s for Amazon ec2 this release cycle.

Scott Moser has done some great work on automating this previously using a small framework of scripts. We discussed refactoring to use Python and boto to make the testing a bit easier to maintain and extend going forwards. This also allows re-use the existing Python unittest + subunit approach from the ISO testing project for testing each ec2 instance as it was started.

An initial test release of the code is available for use; you are going to need an AWS account to use this codebase and be aware that running large tests does cost quite alot of $$/££ so be careful!

Getting started

So the first thing you will need todo is install the ubuntu-server-ec2-testing package; this is available in a PPA and is currently only available for the Natty release:

sudo add-apt-repository ppa:ubuntu-server-ec2-testing-dev/testing
sudo apt-get update
sudo apt-get install ubuntu-server-ec2-testing


This installs the base ec2 testing package onto your machine.

Grab some test cases

Test case definitions and configurations are stored in a bzr branch on Launchpad; this allows configuration and the test itself to be managed outside of the packaged code.

bzr branch lp:~ubuntu-server-ec2-testing-dev/+junk/ec2-automated-tests tests

Take a look in the tests directory this creates:

• the default folder contains the test configuration for the ‘default’ test. This includes the cloud-init configuration that will be injected into each ec2 instance and the Python unittest file which tests the instance.
• *.yaml – these are example test suite configuration files; in this example we will use the test-micro.yaml example file

Setup your ec2 credentials

To access ec2 a key and secret is required; this is stored in another yaml file (~/.ec2.yaml):

AWS_ACCESS_KEY_ID: your access key id
AWS_SECRET_ACCESS_KEY: secret associated with key

Credentials can be setup from your account screens in Amazon Web Services.

Run a test suite

The ubuntu-server-ec2-testing package provides two scripts to execute tests:

• run-ubuntu-ec2-test: runs a single test case; run without any parameters for help.
• run-ubuntu-ec2-multi-test: runs a suite of test cases for multiple sizes, root storage options, regions and availability zones.

So in this example we are going to run the test-micro.yaml test suite.  The format should be fairly intuitive:

This suite is a) for maverick b) for the server (desktops later!) c) will run 1 instance of each TestCase d) will run the i386 image on a t1.micro e) in eu-west-1a and eu-west-1b and f) using ebs root filesystem storage. In total this will cost 2 x t1.micro hours (one for each instance).

To execute this test (against the latest maverick published images using the default test):

run-ubuntu-ec2-multi-test -t tests -f tests/test-micro.yaml default

After a short period of time (about 5 minutes) the test suite should have completed. In the current working directory you will find test results (in JUnit XML format) and console output under the eu-west-1a and eu-west-1b folders.

Part 2: integration with Jenkins to follow….

Trip Report: FOSDEM 2011

With 250+ lectures and 5000 attendees FOSDEM is by far and away the largest software development event that I have attended.

The entire event is organised by the community for the community and takes place at the ULB Campus in Brussels.

I spent most of my weekend in the Free Java Devroom; for a language which has fallen behind and become less popular in recent years, the room was extremely well attended to the point where people where being turned away.  I suspect that this was due to the quality of the schedule and the recent changes in the governance structure of the OpenJDK project generating quite alot of interest in the community.

The Free Java Devroom was run by Tom Marble who did a great job keeping things on track and on-time over the weekend.

OpenJDK

Mark Reinhold (Chief Architect, Java Platform Group, Oracle) kicked off the proceedings with a presentation about the current state of the OpenJDK project.

It was clear that Oracle is 100% behind Java; anything at Oracle that is not a database is written in Java so their business is dependent on the popularity of this platform. They currently employ over 20,000 Java developers!

For those of you who don’t know OpenJDK 7 went through a de-scoping exercise shortly after Oracle acquired Sun Microsystems; this re-planning means that OpenJDK 7 should be with us by July 2011 (instead of the end of 2012) and will include the following new features:

• Project Coin; a number of minor language improvements.  Joe Darcy gave an excellent overview of these features in a separate session.
• InvokeDynamic; vm and language extensions to improve performance of dynamic languages built on Java
• Fork/Join; updates to the concurrency and collections frameworks under JSR-166.

The following features have been dropped from OpenJDK 7 and will be delivered in late 2012 in OpenJDK 8:

• Project Jigsaw; modularization of the Java platform and standardization of dependency declarations ala Debian packaging style. Mark ran another session specifically focused on this project.
• Project Lambda; higher developer productivity and better leveraging of multi-core CPUs.
• Remaining language changes from Project Coin.

I understand the need for the split in order to deliver incremental improvements to the Java platform sooner rather than later; however it is frustrating that Jigsaw won’t be delivered until late 2012.  I think that this project would have moved the Java development community forwards in terms of improving dependency management of Java libraries and applications which will make the lives of Linux distribution packagers much easier.

Mark then went on to talk about the new OpenJDK Governing Board that was recently announced.  This generated a-lot of discussion as the board has been appointed rather than elected; 2 people from Oracle (including Mark), 1 from IBM (effectively killing the Apache Harmony project but thats old news now) and two from the community at large (one who is from Eclipse).  Surprisingly other commercial open source companies such as Red Hat who make a significant contribution to OpenJDK are not represented on the board.   The general feel was that for an open source project this was not the right approach; it was suggested that the board be increased to 7 individuals (the last two being elected from the community) to achieve some balance in the governance of the project.

Oracle’s ownership of the Test Compatibility Kit for Java and the licensing of it to projects is generating a lot of ill feeling in the community and with other companies wishing to build compatible Java runtime environments.  Again this generated a-lot of debate; Azul were present in the room and have been waiting for a TCK for over a year now – supposition is that Oracle is blocking this for commercial reasons.

Java Packaging For Linux Distributions

One hour of the schedule was dedicated to packaging of Java for Linux distributions; unfortunately Thierry Carrez was unable to attend and present about ‘Why Linux Distro’s hate Java’ due to illness.

Torsten Werner (Debian Developer, Java Packaging Team) kicked off with a presentation about the history of Java in Debian and the challenges currently faced by the Java Packaging team. The Java tool-chain in Debian is now looking pretty good; Ant and Maven are both packaged with associated CDBS and maven-*-helper packages to aid building Java from source.

Stanislav Ochotnicky (Co-founder Fedora Java SIG) then gave a presentation on what Java upstream projects can do to help downstream Linux distributions package their applications and libraries more easily. This boiled down to a few key points:

• Don’t patch dependent projects as this is effectively branching; get the feature accepted upstream rather than maintain the branch.
• Avoid including obscure, unmaintained projects in your projects dependency chain.
• If you do bundle dependent libraries with your source code, make it clear what they are and which versions you are using.
• If you are using Maven, make the most of it meta-data that the project definition files can include to describe your project.
• In-fact use Maven; it makes packaging easier

I think that this last point is a key point for Linux distro’s going forwards – although Maven is a much larger packaging challenge in terms of dependencies and complexity when compared to Ant, its by convention approach to laying out a Java project, defining meta-data and defining dependencies should ultimately make Maven based projects much easier to package due through tool-chain automation.

The Best of the Rest

In addition to attending the majority of events in the Free Java Devroom I also managed to catch the keynote from Eben Moglen ‘Why Political Liberty Depends on Software Freedom more than even’. Although I don’t agree with everything he said, he did make some good points about Free and Open Source software solutions challenging traditionally propriety/closed source markets; the concept of using wifi mesh networking to remove reliance on network delivery from centrally controlled companies is a neat idea to provide independence and choice (and resilience when the government disables central internet services…).  He talked quite a bit about the ‘Freedom  Box’; an initiative to deliver a small, cheap inexpensive computer to secure freedom in the home – I noticed that there is already a Debian project aligned to this initiative.

Summary

It is clear that Java is at a critical stage in its lifecycle; the decisions that Oracle makes around how this platform will be developed and governed going forwards will be key.   I think that Mark Reinhold has a very difficult job todo; balancing the commercial demands of Oracle whilst maintaining the support of communities who both develop and use the Java platform will be key.

I also think that FOSDEM is a great conference that I would recommend to anyone that is involved in the world of Free and Open Source Software; thanks to all of the volunteers who make FOSDEM happen!

The Ubuntu Server Survey 2011

Your chance to help shape the future direction of Ubuntu Server – http://survey.ubuntu.com/